draft-nadler-sbox.xml (14047B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY nbsp " "> 4 <!ENTITY zwsp "​"> 5 <!ENTITY nbhy "‑"> 6 <!ENTITY wj "⁠"> 7 ]> 8 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 9 category="info" 10 docName="draft-nadler-sbox-1" 11 ipr="trust200902" 12 obsoletes="" 13 updates="" 14 sortRefs="false" 15 submissionType="independent" 16 symRefs="true" 17 tocDepth="3" 18 tocInclude="true" 19 xml:lang="en" 20 version="3"> 21 22 <!-- xml2rfc v2v3 conversion 2.26.0 --> 23 <front> 24 <title abbrev="The GNS SBOX Record Type">The GNS SBOX Record Type</title> 25 <seriesInfo name="LSD" value="0008" /> 26 <author fullname="Sebastian Nadler" initials="S." surname="Nadler"> 27 <organization>Technische Universität München</organization> 28 <address> 29 <email>sebastian.nadler@tum.de</email> 30 </address> 31 </author> 32 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 33 <organization>Fraunhofer AISEC</organization> 34 <address> 35 <postal> 36 <street>Lichtenbergstrasse 11</street> 37 <city>Garching</city> 38 <code>85748</code> 39 <country>Germany</country> 40 </postal> 41 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 42 </address> 43 </author> 44 <workgroup>GNUnet</workgroup> 45 <keyword>name systems</keyword> 46 47 <abstract> 48 <t> This document provides an extension to the GNU Name System (GNS) technical specification <xref 49 target="RFC9498" />. GNS is a decentralized and censorship-resistant domain name 50 resolution protocol that provides a privacy-enhancing alternative to the Domain Name System 51 (DNS) protocols. </t> 52 <t> 53 This document defines the normative wire format of an additional resource record 54 and a modified resolution processes for use by implementers. 55 </t> 56 <t> 57 This specification was developed outside the IETF and does not have 58 IETF consensus. It is published here to inform readers about the 59 function of GNS, guide future GNS implementations, and ensure 60 interoperability among implementations (for example, pre-existing 61 GNUnet implementations). 62 </t> 63 </abstract> 64 </front> 65 <middle> 66 <section anchor="introduction"> 67 <name>Introduction</name> 68 <t> This specification describes additions to the GNU Name System (GNS) <xref target="RFC9498" />, 69 a censorship-resistant, privacy-preserving, and decentralized domain name resolution 70 protocol. GNS cryptographically secures the binding of names to arbitrary tokens, enabling 71 it to double in some respects as an alternative to some of today's public key 72 infrastructures. </t> 73 <t> 74 This LSD document is an extension to the GNS technical specification <xref target="RFC9498" />. 75 It is intended to be read in conjunction with the GNS technical specification. 76 </t> 77 <t> 78 A new record type is defined to extend the GNS to support a wider range of underscore labels. 79 The new record type is called SBOX and is intended to handle all variations of underscore labels the BOX record type is not able to. 80 </t> 81 <t> 82 This document defines the normative wire format of the SBOX resource 83 record and resolution processes for use by implementers. 84 </t> 85 <section> 86 <name>Requirements Notation</name> 87 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", 88 "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD 89 NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", 90 and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in 91 BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, they 92 appear in all capitals, as shown here.</t> 93 </section> 94 </section> 95 <section> 96 <name>Terminology</name> 97 <t>The terminology defined in <xref target="RFC9498" /> also applies to this document.</t> 98 <t>This document includes the following additional terms:</t> 99 <dl> 100 <dt>Underscore label:</dt> 101 <dd> 102 A label is considered an underscore label only if it begins with an underscore. (e.g., "_name") 103 </dd> 104 <dt>Underscore prefix:</dt> 105 <dd> 106 The underscore prefix contains the rightmost underscore label and all subsequent labels to its left. 107 For example, the underscore prefix of "_service._proto.example.gns.alt" is "_service._proto" and 108 the underscore prefix of "c93f1e400.abcd._info.example.gns.alt" is "c93f1e400.abcd._info". 109 </dd> 110 </dl> 111 </section> 112 <section anchor="rrecords"> 113 <name>Resource Records</name> 114 <section anchor="gnsrecords_other"> 115 <name>Auxiliary Records</name> 116 <t> This section defines an additional auxiliary GNS record type. Any implementation <bcp14> 117 SHOULD</bcp14> be able to process the specified record types according to <xref 118 target="record_processing" />. </t> 119 <section anchor="gnsrecords_sbox"> 120 <name>SBOX</name> 121 <t> 122 GNS lookups are expected to return all of the required useful 123 information in one record set. This avoids unnecessary additional 124 lookups and cryptographically ties together information that belongs 125 together, making it impossible for an adversarial storage entity to provide 126 partial answers that might omit information critical for security. 127 </t> 128 <t> 129 This general strategy is incompatible with the 130 special labels used by DNS for SRV and TLSA records. Thus, GNS 131 defines the BOX record format to box up SRV and TLSA records and 132 include them in the record set of the label they are associated 133 with.</t> 134 <t>This way of handling and storing restricts the allowed and processable underscore 135 prefixes to the format of "_SERVICE._PROTOCOL" as well as only services registered in 136 the corresponding IANA registry. A new SBOX record is proposed to enable the use of labels 137 such as "c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._smimecert" and other variations of 138 underscore prefixes for SMIMEA/URI/SRV, and other records. The SBOX 139 record is supposed to handle all variations of underscore prefixes. The idea 140 is to store the string representation of the underscore prefix instead of the service and protocol numbers. 141 A SBOX record boxes the record's type and data as well as the underscore prefix, and adds them to the record set 142 of the associated label. For example, a URI record for "_scheme._trust.example.gns.alt" 143 will be stored as an SBOX record in the record set of "example.gns.alt" with the underscore prefix 144 "_schema._trust" and record type URI and the URI records data.</t> 145 <t>For reference, see also <xref target="RFC8552" />.</t> 146 <t>A SBOX DATA entry is illustrated in <xref 147 target="figure_boxrecord" />.</t> 148 <figure anchor="figure_boxrecord"> 149 <name>The SBOX DATA Wire Format</name> 150 <artwork name="" type="" alt=""> 151 0 8 16 24 32 40 48 56 152 +-----+-----+-----+-----+-----+-----+-----+-----+ 153 | TYPE | PREFIX / 154 +-----------+-----------+ / 155 / / 156 / / 157 +-----------------------------------------------+ 158 / RECORD DATA / 159 / / 160 +-----+-----+-----+-----+-----+-----+-----+-----+ 161 </artwork> 162 </figure> 163 <dl newline="false"> 164 <dt>TYPE:</dt> 165 <dd> 166 The 32-bit record type of the boxed record in network byte order. 167 </dd> 168 <dt>PREFIX:</dt> 169 <dd> A variable-length field containing the first GNS name prefix consisting of multiple 170 labels. The rightmost label <bcp14>MUST</bcp14> begin with an underscore. 171 PREFIX <bcp14>MUST</bcp14> be a zero terminated string. 172 </dd> 173 <dt>RECORD DATA:</dt> 174 <dd> A variable-length field containing the "DATA" format of TYPE as defined for the 175 respective TYPE. Thus, for TYPE values below 2<sup>16</sup>, the format is the same as 176 the respective record type's binary format in DNS. </dd> 177 </dl> 178 <section anchor="gnsrecords_sbox_box"> 179 <name>Overlap of BOX and SBOX records</name> 180 <t> 181 Records saved as BOX records can also be saved as SBOX records. 182 Thus, upon encountering underscore labels processable by BOX records, 183 the resolver must store the labels as their protocol and service numbers, 184 as well as the underscore prefix. This way, the resolver should be able to 185 return all boxed records later, whether they are SBOX or BOX records. 186 More on this in <xref target="resolution" />. 187 BOX records are more efficient for boxing resource records due to their smaller wire format. 188 Therefore, SBOX records are not a replacement for BOX records. 189 </t> 190 </section> 191 </section> 192 </section> 193 </section> 194 <section anchor="resolution"> 195 <name>Name Resolution</name> 196 <section anchor="record_processing"> 197 <name>Record Processing</name> 198 <t> The first step in processing the records remains the same as described in <xref 199 target="RFC9498" /> Section 7. </t> 200 <t> The next step depends on the context of the name being resolved. Case 3, as defined in <xref 201 target="RFC9498" /> Section 7.3, is modified here. All other cases and further processing steps remain the same.</t> 202 <dl newline="false"> 203 <dt>Case 3:</dt> 204 <dd>If the record set contains SBOX records and the name to be resolved is an underscore prefix, 205 the records in the matching SBOX records are part of the final result. 206 The recursion is processed as described in <xref 207 target="sbox_processing" />. 208 Additionally, it <bcp14>MUST</bcp14> be checked whether the record set contains BOX records and the underscore prefix is in the format "_SERVICE._PROTO". 209 If this is the case the matching BOX records are added to the final result. The recursion is processed as described in <xref 210 target="box_processing" />. 211 The final result is the combination of the unboxed record sets of the matched SBOX and BOX records. 212 </dd> 213 </dl> 214 <section anchor="box_processing"> 215 <name>BOX</name> 216 <t> 217 When a BOX record is received, a GNS resolver must unbox it if the 218 name to be resolved continues with "_SERVICE._PROTO". 219 Otherwise, the BOX record is to be left untouched. This way, TLSA 220 (and SRV) records do not require a separate network request, and 221 TLSA records become inseparable from the corresponding address 222 records. 223 </t> 224 </section> 225 <section anchor="sbox_processing"> 226 <name>SBOX</name> 227 <t> 228 When a SBOX record is received, a GNS resolver must unbox it if the 229 name to be resolved continues with an underscore prefix. 230 Otherwise, the SBOX record is to be left untouched. 231 </t> 232 </section> 233 </section> 234 </section> 235 <section anchor="gana"> 236 <name>GANA Considerations</name> 237 <section anchor="gana_gnsrr"> 238 <name>GNS Record Types Registry</name> 239 <t> GANA <xref target="GANA" /> manages the "GNS Record Types" registry. </t> 240 <t> GANA has assigned a number for the record type SBOX defined in this specification in the 241 "GNS Record Types" registry as listed in <xref target="tab_rrtypenums" />. </t> 242 243 <table anchor="tab_rrtypenums"> 244 <name>The GANA GNS Record Types Registry</name> 245 <thead> 246 <tr> 247 <th>Number</th> 248 <th>Name</th> 249 <th>Contact</th> 250 <th>References</th> 251 <th>Comment</th> 252 </tr> 253 </thead> 254 <tbody> 255 <tr> 256 <td>65547</td> 257 <td>SBOX</td> 258 <td>(*)</td> 259 <td>LSD 0008</td> 260 <td>SBOX records</td> 261 </tr> 262 </tbody> 263 <tfoot> 264 <tr> 265 <td align="left" colspan="5">(*): gns-registry@gnunet.org</td> 266 </tr> 267 </tfoot> 268 </table> 269 </section> 270 </section> 271 </middle> 272 <back> 273 <references> 274 <name>References</name> 275 <references> 276 <name>Normative References</name> 277 278 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" /> 279 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" /> 280 281 <reference anchor="GANA" target="https://gana.gnunet.org/"> 282 <front> 283 <title>GNUnet Assigned Numbers Authority (GANA)</title> 284 <author> 285 <organization>GNUnet e.V.</organization> 286 </author> 287 <date year="2023" /> 288 </front> 289 </reference> 290 </references> 291 <references> 292 <name>Informative References</name> 293 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" /> 294 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9498.xml" /> 295 296 </references> 297 </references> 298 </back> 299 </rfc>