summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2023-12-07 15:05:57 +0100
committerMartin Schanzenbach <schanzen@gnunet.org>2023-12-07 15:05:57 +0100
commit51d627798b6442abc52a447c3f58b8b992813753 (patch)
treef52c1b413aee87e53d5470ee4821306652671851
parent851c23ca418972d8efcea52fdd56764debbee99b (diff)
downloadlsd0008-51d627798b6442abc52a447c3f58b8b992813753.tar.gz
lsd0008-51d627798b6442abc52a447c3f58b8b992813753.zip
add draft
Diffstat
-rw-r--r--draft-nadler-sbox.xml420
1 files changed, 420 insertions, 0 deletions
diff --git a/draft-nadler-sbox.xml b/draft-nadler-sbox.xml
new file mode 100644
index 0000000..187d291
--- /dev/null
+++ b/draft-nadler-sbox.xml
@@ -0,0 +1,420 @@
1<?xml version='1.0' encoding='utf-8'?>
2<!DOCTYPE rfc [
3 <!ENTITY nbsp "&#160;">
4 <!ENTITY zwsp "&#8203;">
5 <!ENTITY nbhy "&#8209;">
6 <!ENTITY wj "&#8288;">
7]>
8<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
9 category="info"
10 docName="draft-schanzen-gns-28"
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="0001" />
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 <date month="December" year="2023" />
45 <workgroup>GNUnet</workgroup>
46 <keyword>name systems</keyword>
47
48 <abstract>
49 <t> This document provides an extension to the GNU Name System (GNS) technical specification <xref
50 target="RFC9498" />. GNS is a decentralized and censorship-resistant domain name
51 resolution protocol that provides a privacy-enhancing alternative to the Domain Name System
52 (DNS) protocols. </t>
53 <t>
54 This document defines the normative wire format of an additional resource record
55 and a modifyed resolution processes for use by implementers.
56 </t>
57 <t>
58 This specification was developed outside the IETF and does not have
59 IETF consensus. It is published here to inform readers about the
60 function of GNS, guide future GNS implementations, and ensure
61 interoperability among implementations (for example, pre-existing
62 GNUnet implementations).
63 </t>
64 <!--<t>
65 Additionally, this is the continued-maintenance version of RFC 9498 which
66 is being updated as the work progresses: The Living Standards Document 0010 (LSD0010).
67 </t>-->
68 </abstract>
69 </front>
70 <middle>
71 <section anchor="introduction">
72 <name>Introduction</name>
73 <t> This specification describes additions to the GNU Name System (GNS) <xref target="RFC9498" />,
74 a censorship-resistant, privacy-preserving, and decentralized domain name resolution
75 protocol. GNS cryptographically secures the binding of names to arbitrary tokens, enabling
76 it to double in some respects as an alternative to some of today's public key
77 infrastructures. </t>
78 <!--<t>
79 Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS roughly follows the idea of
80 a local
81 root zone deployment (see <xref target="RFC8806"/>), with the
82 difference that the design encourages alternative roots and
83 does not expect all deployments to use the same or any specific
84 root zone. In the GNS reference implementation, users can
85 autonomously and freely delegate control of names to zones
86 through their local configurations.
87 GNS expects each user to be in control of their setup.
88 By following the guidelines in <xref target="namespace_ambiguity"/>,
89 users should manage to avoid any confusion as to how names are
90 resolved.
91 </t>
92 <t>
93 Name resolution and zone dissemination are based on the
94 principle of a petname system where users can assign local
95 names to zones. The GNS has its roots in ideas from the Simple
96 Distributed Security Infrastructure <xref target="SDSI"/>,
97 enabling the decentralized mapping of secure identifiers to
98 memorable names. One of the first academic descriptions of the
99 cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
100 </t>-->
101 <t>
102 This document defines the normative wire format of resource
103 records and resolution processes for use by implementers.
104 </t>
105 <section>
106 <name>Requirements Notation</name>
107 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
108 "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD
109 NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>",
110 and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
111 BCP&nbsp;14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, they
112 appear in all capitals, as shown here.</t>
113 </section>
114 </section>
115 <section>
116 <name>Terminology</name>
117 <t>The terminology defined in <xref target="RFC9498" /> also applies to this document.</t>
118 </section>
119 <section anchor="rrecords">
120 <name>Resource Records</name>
121 <section anchor="gnsrecords_other">
122 <name>Auxiliary Records</name>
123 <t> This section defines an additional auxiliary GNS record type. Any implementation <bcp14>
124 SHOULD</bcp14> be able to process the specified record types according to <xref
125 target="record_processing" />. </t>
126 <section anchor="gnsrecords_sbox">
127 <name>SBOX</name>
128 <t>
129 GNS lookups are expected to return all of the required useful
130 information in one record set. This avoids unnecessary additional
131 lookups and cryptographically ties together information that belongs
132 together, making it impossible for an adversarial storage entity to provide
133 partial answers that might omit information critical for security.
134 </t>
135 <t>
136 This general strategy is incompatible with the
137 special labels used by DNS for SRV and TLSA records. Thus, GNS
138 defines the BOX record format to box up SRV and TLSA records and
139 include them in the record set of the label they are associated
140 with.</t>
141 <t>This way of handling and storing restricts the allowed and processable underscore
142 labels to the format of "_SERVICE._PROTOCOL" as well as only services registered in
143 the corresponding IANA registry. To support labels
144 "c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._smimecert"
145 for the intended use of SMIMEA record, a new SBOX record is proposed. The SBOX
146 record is supposed to handle all variations of underscore labels. The underlying idea is
147 instead
148 of storing the service and protocol numbers, the string representation of the underscore
149 label and all subsequent labels is stored. A SBOX record boxes the records type, the
150 records
151 data and the underscore label and subsequent labels and adds them to the record set
152 of the associated label. For example, a URI record for "_scheme._trust.exampel.com"
153 will be stored as an SBOX record in the record set of "example.com" with the label
154 "_schema._trust" and record type URI and the URI records data</t>
155 <t>For reference, see also <xref target="RFC8552" />. A SBOX DATA entry is illustrated in <xref
156 target="figure_boxrecord" />. </t>
157 <figure anchor="figure_boxrecord">
158 <name>The SBOX DATA Wire Format</name>
159 <artwork name="" type="" alt="">
1600 8 16 24 32 40 48 56
161+-----+-----+-----+-----+-----+-----+-----+-----+
162| TYPE | LABEL /
163+-----------+-----------+ /
164/ /
165/ /
166+-----------------------------------------------+
167/ RECORD DATA /
168/ /
169+-----+-----+-----+-----+-----+-----+-----+-----+
170 </artwork>
171 </figure>
172 <dl newline="false">
173 <dt>TYPE:</dt>
174 <dd>
175 The 32-bit record type of the boxed record in network byte order.
176 </dd>
177 <dt>LABEL:</dt>
178 <dd> A variable-length field containing the first underscore label and all subsequent
179 labels. Characters are encoded as c-strings and <bcp14>MUST</bcp14> be null
180 terminated. </dd>
181 <dt>RECORD DATA:</dt>
182 <dd> A variable-length field containing the "DATA" format of TYPE as defined for the
183 respective TYPE. Thus, for TYPE values below 2<sup>16</sup>, the format is the same as
184 the respective record type's binary format in DNS. </dd>
185 </dl>
186 </section>
187 </section>
188 </section>
189 <section anchor="resolution">
190 <name>Name Resolution</name>
191 <section anchor="record_processing">
192 <name>Record Processing</name>
193 <t> The first step in processing the records remains the same as described in <xref
194 target="RFC9498" /> Section 4.1. </t>
195 <t> The next step depends on the context of the name being resolved. Case 3, as defined in <xref
196 target="RFC9498" /> Section 4.1, is modified and Case 6 is added to the list: </t>
197 <dl newline="false">
198 <dt>Case 3:</dt>
199 <dd>If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the
200 record set contains one or more matching BOX records, the records in the BOX records are
201 part of the final result and the recursion is processed as described in <xref
202 target="box_processing" />. An additional check for "Case 6" <bcp14>MUST</bcp14> be
203 made if the record set contains SBOX records.</dd>
204 </dl>
205 <dl newline="false">
206 <dt>Case 6:</dt>
207 <dd>If the remainder of the name to be resolved is strating with "_" and the record set
208 contains one or more matching SBOX records, the records in the SBOX records are part of
209 the final result and the recursion is processed as described in <xref
210 target="sbox_processing" />. An additional check for "Case 3" <bcp14>MUST</bcp14> be
211 made if the record set contains BOX records.</dd>
212 </dl>
213 <section anchor="box_processing">
214 <name>BOX</name>
215 <t>
216 When a BOX record is received, a GNS resolver must unbox it if the
217 name to be resolved continues with "_SERVICE._PROTO".
218 Otherwise, the BOX record is to be left untouched. This way, TLSA
219 (and SRV) records do not require a separate network request, and
220 TLSA records become inseparable from the corresponding address
221 records.
222 </t>
223 </section>
224 <section anchor="sbox_processing">
225 <name>SBOX</name>
226 <t>
227 When a SBOX record is received, a GNS resolver must unbox it if the
228 name to be resolved continues with "_" at the start of the next label.
229 Otherwise, the SBOX record is to be left untouched.
230 </t>
231 </section>
232 </section>
233 </section>
234 <section anchor="gana">
235 <name>GANA Considerations</name>
236 <section anchor="gana_gnsrr">
237 <name>GNS Record Types Registry</name>
238 <t> GANA <xref target="GANA" /> manages the "GNS Record Types" registry. </t>
239 <t>Each entry has the following format:
240 </t>
241 <dl newline="false">
242 <dt>Name:</dt>
243 <dd>The name of the record type (case-insensitive ASCII
244 string, restricted to alphanumeric characters). For zone delegation
245 records, the assigned number represents the ztype value of the zone.</dd>
246 <dt>Number:</dt>
247 <dd>A 32-bit number above 65535.</dd>
248 <dt>Comment:</dt>
249 <dd>Optionally, brief English text describing the purpose of
250 the record type (in UTF-8).</dd>
251 <dt>Contact:</dt>
252 <dd>Optionally, the contact information for a person to contact for
253 further information.</dd>
254 <dt>References:</dt>
255 <dd>Optionally, references (such as an RFC) describing the record type.</dd>
256 </dl>
257 <t> GANA has assigned a number for the record type SBOX defined in this specification in the
258 "GNS Record Types" registry as listed in <xref target="tab_rrtypenums" />. </t>
259
260 <table anchor="tab_rrtypenums">
261 <name>The GANA GNS Record Types Registry</name>
262 <thead>
263 <tr>
264 <th>Number</th>
265 <th>Name</th>
266 <th>Contact</th>
267 <th>References</th>
268 <th>Comment</th>
269 </tr>
270 </thead>
271 <tbody>
272 <tr>
273 <td>65536</td>
274 <td>PKEY</td>
275 <td>(*)</td>
276 <td>RFC 9498</td>
277 <td>GNS zone delegation (PKEY)</td>
278 </tr>
279 <tr>
280 <td>65537</td>
281 <td>NICK</td>
282 <td>(*)</td>
283 <td>RFC 9498</td>
284 <td>GNS zone nickname</td>
285 </tr>
286 <tr>
287 <td>65538</td>
288 <td>LEHO</td>
289 <td>(*)</td>
290 <td>RFC 9498</td>
291 <td>GNS legacy hostname</td>
292 </tr>
293 <tr>
294 <td>65540</td>
295 <td>GNS2DNS</td>
296 <td>(*)</td>
297 <td>RFC 9498</td>
298 <td>Delegation to DNS</td>
299 </tr>
300 <tr>
301 <td>65541</td>
302 <td>BOX</td>
303 <td>(*)</td>
304 <td>RFC 9498</td>
305 <td>Box records</td>
306 </tr>
307 <tr>
308 <td>65547</td>
309 <td>SBOX</td>
310 <td>(*)</td>
311 <td>LSD 0010</td>
312 <td>SBox records</td>
313 </tr>
314 <tr>
315 <td>65551</td>
316 <td>REDIRECT</td>
317 <td>(*)</td>
318 <td>RFC 9498</td>
319 <td>Redirection record</td>
320 </tr>
321 <tr>
322 <td>65556</td>
323 <td>EDKEY</td>
324 <td>(*)</td>
325 <td>RFC 9498</td>
326 <td>GNS zone delegation (EDKEY)</td>
327 </tr>
328 </tbody>
329 <tfoot>
330 <tr>
331 <td align="left" colspan="5">(*): gns-registry@gnunet.org</td>
332 </tr>
333 </tfoot>
334 </table>
335 </section>
336 </section>
337 </middle>
338 <back>
339 <references>
340 <name>References</name>
341 <references>
342 <name>Normative References</name>
343
344 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml" />
345 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" />
346 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml" />
347 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
348 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml" />
349 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml" />
350 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml" />
351 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml" />
352 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml" />
353 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml" />
354 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml" />
355 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml" />
356 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml" />
357 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml" />
358 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml" />
359 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml" />
360 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" />
361 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
362 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml" />
363 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml" />
364
365 <reference anchor="GANA" target="https://gana.gnunet.org/">
366 <front>
367 <title>GNUnet Assigned Numbers Authority (GANA)</title>
368 <author>
369 <organization>GNUnet e.V.</organization>
370 </author>
371 <date year="2023" />
372 </front>
373 </reference>
374 </references>
375 <references>
376 <name>Informative References</name>
377 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" />
378 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9498.xml" />
379
380 <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280-9_9">
381 <front>
382 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>
383 <author initials="M." surname="Wachs" fullname="Matthias Wachs">
384 <organization>Technische Universität München</organization>
385 </author>
386 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
387 <organization>Technische Universität München</organization>
388 </author>
389 <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
390 <organization>Technische Universität München</organization>
391 </author>
392 <date month="October" year="2014" />
393 </front>
394 <refcontent>13th International Conference on Cryptology and Network Security (CANS)</refcontent>
395 <seriesInfo name="DOI" value="10.13140/2.1.4642.3044" />
396 </reference>
397
398 <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git">
399 <front>
400 <title>gnunet.git - GNUnet core repository</title>
401 <author>
402 <organization>GNUnet e.V.</organization>
403 </author>
404 <date year="2023" />
405 </front>
406 </reference>
407
408 <reference anchor="GNUnet" target="https://gnunet.org">
409 <front>
410 <title>The GNUnet Project (Home Page)</title>
411 <author>
412 <organization>GNUnet e.V.</organization>
413 </author>
414 <date year="2023" />
415 </front>
416 </reference>
417 </references>
418 </references>
419 </back>
420</rfc>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-12 08:21:05 +0000