diff options
Diffstat (limited to 'draft-schanzen-gns-01.xml')
-rw-r--r-- | draft-schanzen-gns-01.xml | 1918 |
1 files changed, 1918 insertions, 0 deletions
diff --git a/draft-schanzen-gns-01.xml b/draft-schanzen-gns-01.xml new file mode 100644 index 0000000..b7597ac --- /dev/null +++ b/draft-schanzen-gns-01.xml | |||
@@ -0,0 +1,1918 @@ | |||
1 | <?xml version='1.0' encoding='utf-8'?> | ||
2 | <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [ | ||
3 | <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"> | ||
4 | <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"> | ||
5 | <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> | ||
6 | <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> | ||
7 | <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> | ||
8 | <!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> | ||
9 | <!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml"> | ||
10 | <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> | ||
11 | <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> | ||
12 | <!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml"> | ||
13 | <!ENTITY RFC6781 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml"> | ||
14 | <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> | ||
15 | <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> | ||
16 | <!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml"> | ||
17 | <!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml"> | ||
18 | <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> | ||
19 | ]> | ||
20 | <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||
21 | <?rfc strict="yes" ?> | ||
22 | <?rfc toc="yes" ?> | ||
23 | <?rfc symrefs="yes"?> | ||
24 | <?rfc sortrefs="yes" ?> | ||
25 | <?rfc compact="yes" ?> | ||
26 | <?rfc subcompact="no" ?> | ||
27 | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> | ||
28 | <!-- xml2rfc v2v3 conversion 2.26.0 --> | ||
29 | <front> | ||
30 | <title abbrev="The GNU Name System"> | ||
31 | The GNU Name System | ||
32 | </title> | ||
33 | <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-01"/> | ||
34 | <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> | ||
35 | <organization>GNUnet e.V.</organization> | ||
36 | <address> | ||
37 | <postal> | ||
38 | <street>Boltzmannstrasse 3</street> | ||
39 | <city>Garching</city> | ||
40 | <code>85748</code> | ||
41 | <country>DE</country> | ||
42 | </postal> | ||
43 | <email>schanzen@gnunet.org</email> | ||
44 | </address> | ||
45 | </author> | ||
46 | <author fullname="Christian Grothoff" initials="C." surname="Grothoff"> | ||
47 | <organization>Berner Fachhochschule</organization> | ||
48 | <address> | ||
49 | <postal> | ||
50 | <street>Hoeheweg 80</street> | ||
51 | <city>Biel/Bienne</city> | ||
52 | <code>2501</code> | ||
53 | <country>CH</country> | ||
54 | </postal> | ||
55 | <email>grothoff@gnunet.org</email> | ||
56 | </address> | ||
57 | </author> | ||
58 | <author fullname="Bernd Fix" initials="B." surname="Fix"> | ||
59 | <organization>GNUnet e.V.</organization> | ||
60 | <address> | ||
61 | <postal> | ||
62 | <street>Boltzmannstrasse 3</street> | ||
63 | <city>Garching</city> | ||
64 | <code>85748</code> | ||
65 | <country>DE</country> | ||
66 | </postal> | ||
67 | <email>fix@gnunet.org</email> | ||
68 | </address> | ||
69 | </author> | ||
70 | |||
71 | <!-- Meta-data Declarations --> | ||
72 | <area>General</area> | ||
73 | <workgroup>Independent Stream</workgroup> | ||
74 | <keyword>name systems</keyword> | ||
75 | <abstract> | ||
76 | <t>This document contains the GNU Name System (GNS) technical specification.</t> | ||
77 | </abstract> | ||
78 | </front> | ||
79 | <middle> | ||
80 | <section anchor="introduction" numbered="true" toc="default"> | ||
81 | <name>Introduction</name> | ||
82 | <t> | ||
83 | The Domain Name System (DNS) is a unique distributed database and a vital | ||
84 | service for most Internet applications. While DNS is distributed, it | ||
85 | relies on centralized, trusted registrars to provide globally unique | ||
86 | names. As the awareness of the central role DNS plays on the Internet | ||
87 | rises, various institutions are using their power (including legal means) | ||
88 | to engage in attacks on the DNS, thus threatening the global availability | ||
89 | and integrity of information on the Internet. | ||
90 | </t> | ||
91 | <t> | ||
92 | DNS was not designed with security as a goal. This makes it very | ||
93 | vulnerable, especially to attackers that have the technical capabilities | ||
94 | of an entire nation state at their disposal. | ||
95 | This specification describes a censorship-resistant, privacy-preserving | ||
96 | and decentralized name system: The GNU Name System (GNS). It is designed | ||
97 | to provide a secure alternative to DNS, especially when censorship or | ||
98 | manipulation is encountered. GNS can bind names to any kind of | ||
99 | cryptographically secured token, enabling it to double in some respects as | ||
100 | even as an alternative to some of today’s Public Key Infrastructures, in | ||
101 | particular X.509 for the Web. | ||
102 | </t> | ||
103 | <t> | ||
104 | This document contains the GNU Name System (GNS) technical specification | ||
105 | of the GNU Name System <xref target="GNS" />, a fully decentralized and censorship-resistant | ||
106 | name system. GNS provides a privacy-enhancing alternative to the Domain | ||
107 | Name System (DNS). The design of GNS incorporates the capability to | ||
108 | integrate and coexist with DNS. GNS is based on the principle of a petname | ||
109 | system and builds on ideas from the Simple Distributed Security | ||
110 | Infrastructure (SDSI), addressing a central issue with the decentralized | ||
111 | mapping of secure identifiers to memorable names: namely the impossibility | ||
112 | of providing a global, secure and memorable mapping without a trusted | ||
113 | authority. GNS uses the transitivity in the SDSI design to replace the | ||
114 | trusted root with secure delegation of authority thus making petnames | ||
115 | useful to other users while operating under a very strong adversary model. | ||
116 | </t> | ||
117 | <t> | ||
118 | This document defines the normative wire format of resource records, resolution processes, | ||
119 | cryptographic routines and security considerations for use by implementors. | ||
120 | </t> | ||
121 | <t> | ||
122 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | ||
123 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | ||
124 | "OPTIONAL" in this document are to be interpreted as described | ||
125 | in <xref target="RFC2119"/>. | ||
126 | </t> | ||
127 | <t> | ||
128 | |||
129 | </t> | ||
130 | </section> | ||
131 | <section anchor="zones" numbered="true" toc="default"> | ||
132 | <name>Zones</name> | ||
133 | <t> | ||
134 | A zone in GNS is defined by a public/private ECDSA key pair (d,zk), | ||
135 | where d is the private key and zk the corresponding public key. | ||
136 | GNS employs the curve parameters of the twisted edwards representation | ||
137 | of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519) | ||
138 | with the ECDSA scheme (<xref target="RFC6979" />). | ||
139 | In the following, we use the following naming convention for our | ||
140 | cryptographic primitives: | ||
141 | </t> | ||
142 | <dl> | ||
143 | <dt>d</dt> | ||
144 | <dd> | ||
145 | is a 256-bit ECDSA private key. | ||
146 | In GNS, records are signed using a key derived from "d" as described in | ||
147 | <xref target="publish" />. | ||
148 | </dd> | ||
149 | <dt>p</dt> | ||
150 | <dd> | ||
151 | is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e. | ||
152 | 2^255 - 19. | ||
153 | </dd> | ||
154 | <dt>B</dt> | ||
155 | <dd> | ||
156 | is the group generator (X(P),Y(P)) of edwards25519 as defined in | ||
157 | <xref target="RFC7748" />. | ||
158 | </dd> | ||
159 | <dt>L</dt> | ||
160 | <dd> | ||
161 | is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. | ||
162 | </dd> | ||
163 | <dt>zk</dt> | ||
164 | <dd> | ||
165 | is the ECDSA public key corresponding to d. It is defined in | ||
166 | <xref target="RFC6979" /> as the curve point d*B where B is the group | ||
167 | generator of the elliptic curve. The public key is used to uniquely | ||
168 | identify a GNS zone and is referred to as the "zone key". | ||
169 | </dd> | ||
170 | </dl> | ||
171 | </section> | ||
172 | <section anchor="rrecords" numbered="true" toc="default"> | ||
173 | <name>Resource Records</name> | ||
174 | <t> | ||
175 | A GNS implementor MUST provide a mechanism to create and manage resource | ||
176 | records for local zones. A local zone is established by creating a zone | ||
177 | key pair. Records may be added to each zone, hence a (local) persistency | ||
178 | mechanism for resource records and zones must be provided. | ||
179 | This local zone database is used by the GNS resolver implementation | ||
180 | and to publish record information. | ||
181 | </t> | ||
182 | <t> | ||
183 | A GNS resource record holds the data of a specific record in a zone. | ||
184 | The resource record format is defined as follows: | ||
185 | </t> | ||
186 | <figure anchor="figure_gnsrecord"> | ||
187 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
188 | 0 8 16 24 32 40 48 56 | ||
189 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
190 | | EXPIRATION | | ||
191 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
192 | | DATA SIZE | TYPE | | ||
193 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
194 | | FLAGS | DATA / | ||
195 | +-----+-----+-----+-----+ / | ||
196 | / / | ||
197 | / / | ||
198 | ]]></artwork> | ||
199 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
200 | </figure> | ||
201 | <t>where:</t> | ||
202 | <dl> | ||
203 | <dt>EXPIRATION</dt> | ||
204 | <dd> | ||
205 | denotes the absolute 64-bit expiration date of the record. | ||
206 | In microseconds since midnight (0 hour), January 1, 1970 in network | ||
207 | byte order. | ||
208 | </dd> | ||
209 | <dt>DATA SIZE</dt> | ||
210 | <dd> | ||
211 | denotes the 32-bit size of the DATA field in bytes and in network byte | ||
212 | order. | ||
213 | </dd> | ||
214 | <dt>TYPE</dt> | ||
215 | <dd> | ||
216 | is the 32-bit resource record type. This type can be one of the GNS resource | ||
217 | records as defined in <xref target="rrecords" /> or a DNS record | ||
218 | type as defined in <xref target="RFC1035" /> or any of the | ||
219 | complementary standardized DNS resource record types. This value must be | ||
220 | stored in network byte order. Note that values | ||
221 | below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />). | ||
222 | </dd> | ||
223 | <dt>FLAGS</dt> | ||
224 | <dd> | ||
225 | is a 32-bit resource record flags field (see below). | ||
226 | </dd> | ||
227 | <dt>DATA</dt> | ||
228 | <dd> | ||
229 | the variable-length resource record data payload. The contents are defined | ||
230 | by the | ||
231 | respective type of the resource record. | ||
232 | </dd> | ||
233 | </dl> | ||
234 | <t> | ||
235 | Flags indicate metadata surrounding the resource record. A flag | ||
236 | value of 0 indicates that all flags are unset. The following | ||
237 | illustrates the flag distribution in the 32-bit flag value of a | ||
238 | resource record:</t> | ||
239 | <figure anchor="figure_flag"> | ||
240 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
241 | ... 5 4 3 2 1 0 | ||
242 | ------+--------+--------+--------+--------+--------+ | ||
243 | / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / | | ||
244 | ------+--------+--------+--------+--------+--------+ | ||
245 | ]]></artwork> | ||
246 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
247 | </figure> | ||
248 | <t> | ||
249 | where: | ||
250 | </t> | ||
251 | <dl> | ||
252 | <dt>SHADOW</dt> | ||
253 | <dd> | ||
254 | If this flag is set, this record should be ignored by resolvers unless all (other) | ||
255 | records of the same record type have expired. Used to allow zone publishers to | ||
256 | facilitate good performance when records change by allowing them to put future | ||
257 | values of records into the DHT. This way, future values can propagate and may be | ||
258 | cached before the transition becomes active. | ||
259 | </dd> | ||
260 | <dt>EXPREL</dt> | ||
261 | <dd> | ||
262 | The expiration time value of the record is a relative time (still in microseconds) | ||
263 | and not an absolute time. This flag should never be encountered by a resolver | ||
264 | for records obtained from the DHT, but might be present when a resolver looks up | ||
265 | private records of a zone hosted locally. | ||
266 | </dd> | ||
267 | <dt> | ||
268 | SUPPL | ||
269 | </dt> | ||
270 | <dd> | ||
271 | This is a supplemental record. It is provided in addition to the | ||
272 | other records. This flag indicates that this record is not explicitly | ||
273 | managed alongside the other records under the respective name but | ||
274 | may be useful for the application. This flag should only be encountered | ||
275 | by a resolver for records obtained from the DHT. | ||
276 | </dd> | ||
277 | <dt>PRIVATE</dt> | ||
278 | <dd> | ||
279 | This is a private record of this peer and it should thus not be | ||
280 | published in the DHT. Thus, this flag should never be encountered by | ||
281 | a resolver for records obtained from the DHT. | ||
282 | Private records should still be considered just like | ||
283 | regular records when resolving labels in local zones. | ||
284 | </dd> | ||
285 | </dl> | ||
286 | <section anchor="gnsrecords_numbers" numbered="true" toc="default"> | ||
287 | <name>Record Types</name> | ||
288 | <t> | ||
289 | A registry of GNS Record Types is described in Section 10. The | ||
290 | registration policy for this registry is "First Come First Served", as | ||
291 | described in <xref target="RFC8126"/>. When requesting new entries, careful | ||
292 | consideration of the following criteria is strongly advised: | ||
293 | FIXME: ausdenken was wir da gerne haetten. | ||
294 | </t> | ||
295 | </section> | ||
296 | <section anchor="gnsrecords_pkey" numbered="true" toc="default"> | ||
297 | <name>PKEY</name> | ||
298 | <t>In GNS, a delegation of a label to a zone is represented through a PKEY | ||
299 | record. A PKEY resource record contains the public key of the zone to | ||
300 | delegate to. A PKEY record MUST be the only record under a label. No other | ||
301 | records are allowed. A PKEY DATA entry has the following format:</t> | ||
302 | <figure anchor="figure_pkeyrecord"> | ||
303 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
304 | 0 8 16 24 32 40 48 56 | ||
305 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
306 | | PUBLIC KEY | | ||
307 | | | | ||
308 | | | | ||
309 | | | | ||
310 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
311 | ]]></artwork> | ||
312 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
313 | </figure> | ||
314 | <t> | ||
315 | where: | ||
316 | </t> | ||
317 | <dl> | ||
318 | <dt>PUBLIC KEY</dt> | ||
319 | <dd> | ||
320 | A 256-bit ECDSA zone key. | ||
321 | </dd> | ||
322 | </dl> | ||
323 | </section> | ||
324 | <section anchor="gnsrecords_gns2dns" numbered="true" toc="default"> | ||
325 | <name>GNS2DNS</name> | ||
326 | <t>It is possible to delegate a label back into DNS through a GNS2DNS record. | ||
327 | The resource record contains a DNS name for the resolver to continue with | ||
328 | in DNS followed by a DNS server. Both names are in the format defined in | ||
329 | <xref target="RFC1034" /> for DNS names. | ||
330 | A GNS2DNS DATA entry has the following format:</t> | ||
331 | <figure anchor="figure_gns2dnsrecord"> | ||
332 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
333 | 0 8 16 24 32 40 48 56 | ||
334 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
335 | | DNS NAME | | ||
336 | / / | ||
337 | / / | ||
338 | | | | ||
339 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
340 | | DNS SERVER NAME | | ||
341 | / / | ||
342 | / / | ||
343 | | | | ||
344 | +-----------------------------------------------+ | ||
345 | ]]></artwork> | ||
346 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
347 | </figure> | ||
348 | <t> | ||
349 | where: | ||
350 | </t> | ||
351 | <dl> | ||
352 | <dt>DNS NAME</dt> | ||
353 | <dd> | ||
354 | The name to continue with in DNS (0-terminated). | ||
355 | </dd> | ||
356 | <dt>DNS SERVER NAME</dt> | ||
357 | <dd> | ||
358 | The DNS server to use. May be an IPv4/IPv6 address in dotted decimal | ||
359 | form or a DNS name. It may also be a relative GNS name ending with a | ||
360 | "+" top-level domain. The value is UTF-8 encoded (also for DNS names) | ||
361 | and 0-terminated. | ||
362 | </dd> | ||
363 | </dl> | ||
364 | </section> | ||
365 | |||
366 | <section anchor="gnsrecords_leho" numbered="true" toc="default"> | ||
367 | <name>LEHO</name> | ||
368 | <t>Legacy hostname records can be used by applications that are expected | ||
369 | to supply a DNS name on the application layer. The most common use case | ||
370 | is HTTP virtual hosting, which as-is would not work with GNS names as | ||
371 | those may not be globally unique. | ||
372 | |||
373 | A LEHO resource record is expected to be found together in a single | ||
374 | resource record with an IPv4 or IPv6 address. | ||
375 | A LEHO DATA entry has the following format:</t> | ||
376 | <figure anchor="figure_lehorecord"> | ||
377 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
378 | 0 8 16 24 32 40 48 56 | ||
379 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
380 | | LEGACY HOSTNAME | | ||
381 | / / | ||
382 | / / | ||
383 | | | | ||
384 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
385 | ]]></artwork> | ||
386 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
387 | </figure> | ||
388 | <t> | ||
389 | where: | ||
390 | </t> | ||
391 | <dl> | ||
392 | <dt>LEGACY HOSTNAME</dt> | ||
393 | <dd> | ||
394 | A UTF-8 string (which is not 0-terminated) representing the legacy hostname. | ||
395 | </dd> | ||
396 | </dl> | ||
397 | <t> | ||
398 | NOTE: If an application uses a LEHO value in an HTTP request header | ||
399 | (e.g. "Host:" header) it must be converted to a punycode representation | ||
400 | <xref target="RFC5891" />. | ||
401 | </t> | ||
402 | </section> | ||
403 | <section anchor="gnsrecords_nick" numbered="true" toc="default"> | ||
404 | <name>NICK</name> | ||
405 | <t> | ||
406 | Nickname records can be used by zone administrators to publish an | ||
407 | indication on what label this zone prefers to be referred to. | ||
408 | This is a suggestion to other zones what label to use when creating a | ||
409 | PKEY (<xref target="gnsrecords_pkey" />) record containing this zone's | ||
410 | public zone key. | ||
411 | This record SHOULD only be stored under the empty label "@" but MAY be | ||
412 | returned with record sets under any label as a supplemental record. | ||
413 | <xref target="nick_processing"/> details how a resolver must process | ||
414 | supplemental and non-supplemental NICK records. | ||
415 | A NICK DATA entry has the following format: | ||
416 | </t> | ||
417 | <figure anchor="figure_nickrecord"> | ||
418 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
419 | 0 8 16 24 32 40 48 56 | ||
420 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
421 | | NICKNAME | | ||
422 | / / | ||
423 | / / | ||
424 | | | | ||
425 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
426 | ]]></artwork> | ||
427 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
428 | </figure> | ||
429 | <t> | ||
430 | where: | ||
431 | </t> | ||
432 | <dl> | ||
433 | <dt>NICKNAME</dt> | ||
434 | <dd> | ||
435 | A UTF-8 string (which is not 0-terminated) representing the preferred | ||
436 | label of the zone. This string MUST NOT include a "." character. | ||
437 | </dd> | ||
438 | </dl> | ||
439 | </section> | ||
440 | <section anchor="gnsrecords_box" numbered="true" toc="default"> | ||
441 | <name>BOX</name> | ||
442 | <t> | ||
443 | In GNS, every "." in a name delegates to another zone, and | ||
444 | GNS lookups are expected to return all of the required useful | ||
445 | information in one record set. This is incompatible with the | ||
446 | special labels used by DNS for SRV and TLSA records. Thus, GNS | ||
447 | defines the BOX record format to box up SRV and TLSA records and | ||
448 | include them in the record set of the label they are associated | ||
449 | with. For example, a | ||
450 | TLSA record for "_https._tcp.example.org" will be stored in the record set of | ||
451 | "example.org" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6 | ||
452 | (tcp) and record TYPE "TLSA". | ||
453 | For reference, see also <xref target="RFC2782" />. | ||
454 | A BOX DATA entry has the following format: | ||
455 | </t> | ||
456 | <figure anchor="figure_boxrecord"> | ||
457 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
458 | 0 8 16 24 32 40 48 56 | ||
459 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
460 | | PROTO | SVC | TYPE | | ||
461 | +-----------+-----------------------------------+ | ||
462 | | RECORD DATA | | ||
463 | / / | ||
464 | / / | ||
465 | | | | ||
466 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
467 | ]]></artwork> | ||
468 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
469 | </figure> | ||
470 | <t> | ||
471 | where: | ||
472 | </t> | ||
473 | <dl> | ||
474 | <dt>PROTO</dt> | ||
475 | <dd> | ||
476 | the 16-bit protocol number, e.g. 6 for tcp. In network byte order. | ||
477 | </dd> | ||
478 | <dt>SVC</dt> | ||
479 | <dd> | ||
480 | the 16-bit service value of the boxed record, i.e. the port number. | ||
481 | In network byte order. | ||
482 | </dd> | ||
483 | <dt>TYPE</dt> | ||
484 | <dd> | ||
485 | is the 32-bit record type of the boxed record. In network byte order. | ||
486 | </dd> | ||
487 | <dt>RECORD DATA</dt> | ||
488 | <dd> | ||
489 | is a variable length field containing the "DATA" format of TYPE as | ||
490 | defined for the respective TYPE in DNS. | ||
491 | </dd> | ||
492 | </dl> | ||
493 | </section> | ||
494 | <section anchor="gnsrecords_vpn" numbered="true" toc="default"> | ||
495 | <name>VPN</name> | ||
496 | <t> | ||
497 | A VPN DATA entry has the following format:</t> | ||
498 | <figure anchor="figure_vpnrecord"> | ||
499 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
500 | 0 8 16 24 32 40 48 56 | ||
501 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
502 | | HOSTING PEER PUBLIC KEY | | ||
503 | | (256 bits) | | ||
504 | | | | ||
505 | | | | ||
506 | +-----------+-----------------------------------+ | ||
507 | | PROTO | SERVICE NAME | | ||
508 | +-----------+ + | ||
509 | / / | ||
510 | / / | ||
511 | | | | ||
512 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
513 | ]]></artwork> | ||
514 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
515 | </figure> | ||
516 | <t> | ||
517 | where: | ||
518 | </t> | ||
519 | <dl> | ||
520 | <dt>HOSTING PEER PUBLIC KEY</dt> | ||
521 | <dd> | ||
522 | is a 256-bit EdDSA public key identifying the peer hosting the | ||
523 | service. | ||
524 | </dd> | ||
525 | <dt>PROTO</dt> | ||
526 | <dd> | ||
527 | the 16-bit protocol number, e.g. 6 for TCP. In network byte order. | ||
528 | </dd> | ||
529 | <dt>SERVICE NAME</dt> | ||
530 | <dd> | ||
531 | a shared secret used to identify the service at the hosting peer, | ||
532 | used to derive the port number requird to connect to the service. | ||
533 | The service name MUST be a 0-terminated UTF-8 string. | ||
534 | </dd> | ||
535 | </dl> | ||
536 | </section> | ||
537 | </section> | ||
538 | |||
539 | <section anchor="publish" numbered="true" toc="default"> | ||
540 | <name>Publishing Records</name> | ||
541 | <t> | ||
542 | GNS resource records are published in a distributed hash table (DHT). | ||
543 | We assume that a DHT provides two functions: GET(key) and PUT(key,value). | ||
544 | In GNS, resource records are grouped by their respective labels, | ||
545 | encrypted and published together in a single resource records block | ||
546 | (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK). | ||
547 | The key "q" which is derived from the zone key "zk" and the respective | ||
548 | label of the contained records. | ||
549 | </t> | ||
550 | <section anchor="blinding" numbered="true" toc="default"> | ||
551 | <name>Key Derivations</name> | ||
552 | <t> | ||
553 | Given a label, the DHT key "q" is derived as follows: | ||
554 | </t> | ||
555 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
556 | PRK_h := HKDF-Extract ("key-derivation", zk) | ||
557 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | ||
558 | d_h := h * d mod L | ||
559 | zk_h := h mod L * zk | ||
560 | q := SHA512 (zk_h) | ||
561 | ]]></artwork> | ||
562 | <t> | ||
563 | We use a hash-based key derivation function (HKDF) as defined in | ||
564 | <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction | ||
565 | phase and HMAC-SHA256 for the expansion phase. | ||
566 | </t> | ||
567 | <dl> | ||
568 | <dt>PRK_h</dt> | ||
569 | <dd> | ||
570 | is key material retrieved using an HKDF using the string | ||
571 | "key-derivation" as salt and the public zone key "zk" as initial | ||
572 | keying material. | ||
573 | </dd> | ||
574 | <dt>h</dt> | ||
575 | <dd> | ||
576 | is the 512-bit HKDF expansion result. The expansion info input is a | ||
577 | concatenation of the label and string "gns". | ||
578 | </dd> | ||
579 | <dt>d</dt> | ||
580 | <dd> | ||
581 | is the 256-bit private zone key as defined in <xref target="zones" />. | ||
582 | </dd> | ||
583 | <dt>label</dt> | ||
584 | <dd>is a UTF-8 string under which the resource records are published. | ||
585 | </dd> | ||
586 | <dt>d_h</dt> | ||
587 | <dd> | ||
588 | is a 256-bit private key derived from the "d" using the | ||
589 | keying material "h". | ||
590 | </dd> | ||
591 | <dt>zk_h</dt> | ||
592 | <dd> | ||
593 | is a 256-bit public key derived from the zone key "zk" using the | ||
594 | keying material "h". | ||
595 | </dd> | ||
596 | <dt>L</dt> | ||
597 | <dd> | ||
598 | is the prime-order subgroup as defined in <xref target="zones" />. | ||
599 | </dd> | ||
600 | <dt>q</dt> | ||
601 | <dd> | ||
602 | Is the 512-bit DHT key under which the resource records block is | ||
603 | published. | ||
604 | It is the SHA512 hash over the public key "zk_h" corresponding to the | ||
605 | derived private key "d_h". | ||
606 | </dd> | ||
607 | </dl> | ||
608 | <t> | ||
609 | We point out that the multiplication of "zk" with "h" is a point multiplication, | ||
610 | while the multiplication of "d" with "h" is a scalar multiplication. | ||
611 | </t> | ||
612 | </section> | ||
613 | <section anchor="wire" numbered="true" toc="default"> | ||
614 | <name>Resource Records Block</name> | ||
615 | <t> | ||
616 | GNS records are grouped by their labels and published as a single | ||
617 | block in the DHT. The grouped record sets MAY be paired with any | ||
618 | number of supplemental records. Supplemental records must have the | ||
619 | supplemental flag set (See <xref target="rrecords"/>). | ||
620 | The contained resource records are encrypted using a symmetric | ||
621 | encryption scheme. | ||
622 | A GNS implementation must publish RRBLOCKs | ||
623 | in accordance to the properties and recommendations of the underlying | ||
624 | DHT. This may include a periodic refresh publication. | ||
625 | A GNS RRBLOCK has the following format: | ||
626 | </t> | ||
627 | <figure anchor="figure_record_block"> | ||
628 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
629 | 0 8 16 24 32 40 48 56 | ||
630 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
631 | | SIGNATURE | | ||
632 | | | | ||
633 | | | | ||
634 | | | | ||
635 | | | | ||
636 | | | | ||
637 | | | | ||
638 | | | | ||
639 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
640 | | PUBLIC KEY | | ||
641 | | | | ||
642 | | | | ||
643 | | | | ||
644 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
645 | | SIZE | PURPOSE | | ||
646 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
647 | | EXPIRATION | | ||
648 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
649 | | BDATA / | ||
650 | / / | ||
651 | / | | ||
652 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
653 | ]]></artwork> | ||
654 | </figure> | ||
655 | <t>where:</t> | ||
656 | <dl> | ||
657 | <dt>SIGNATURE</dt> | ||
658 | <dd> | ||
659 | A 512-bit ECDSA deterministic signature compliant with | ||
660 | <xref target="RFC6979" />. The signature is computed over the data | ||
661 | following the PUBLIC KEY field. | ||
662 | The signature is created using the derived private key "d_h" (see | ||
663 | <xref target="publish" />). | ||
664 | </dd> | ||
665 | <dt>PUBLIC KEY</dt> | ||
666 | <dd> | ||
667 | is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The | ||
668 | wire format of this value is defined in <xref target="RFC8032" />, | ||
669 | Section 5.1.5. | ||
670 | </dd> | ||
671 | <dt>SIZE</dt> | ||
672 | <dd> | ||
673 | A 32-bit value containing the length of the signed data following the | ||
674 | PUBLIC KEY field in network byte order. This value always includes the | ||
675 | length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in | ||
676 | addition to the length of the BDATA. While a 32-bit value is used, | ||
677 | implementations MAY refuse to publish blocks beyond a certain | ||
678 | size significantly below 4 GB. However, a minimum block size of | ||
679 | 62 kilobytes MUST be supported. | ||
680 | <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE --> | ||
681 | </dd> | ||
682 | <dt>PURPOSE</dt> | ||
683 | <dd> | ||
684 | A 32-bit signature purpose flag. This field MUST be 15 (in network | ||
685 | byte order). | ||
686 | </dd> | ||
687 | <dt>EXPIRATION</dt> | ||
688 | <dd> | ||
689 | Specifies when the RRBLOCK expires and the encrypted block | ||
690 | SHOULD be removed from the DHT and caches as it is likely stale. | ||
691 | However, applications MAY continue to use non-expired individual | ||
692 | records until they expire. The value MUST be set to the | ||
693 | expiration time of the resource record contained within this block with the | ||
694 | smallest expiration time. | ||
695 | If a records block includes shadow records, then the maximum | ||
696 | expiration time of all shadow records with matching type and the | ||
697 | expiration times of the non-shadow records is considered. | ||
698 | This is a 64-bit absolute date in microseconds since midnight | ||
699 | (0 hour), January 1, 1970 in network byte order. | ||
700 | </dd> | ||
701 | <dt>BDATA</dt> | ||
702 | <dd> | ||
703 | The encrypted resource records with a total size of SIZE - 16. | ||
704 | </dd> | ||
705 | </dl> | ||
706 | </section> | ||
707 | <section anchor="recordencryption" numbered="true" toc="default"> | ||
708 | <name>Record Data Encryption and Decryption</name> | ||
709 | <t> | ||
710 | A symmetric encryption scheme is used to encrypt the resource records | ||
711 | set RDATA into the BDATA field of a GNS RRBLOCK. | ||
712 | The wire format of the RDATA looks as follows: | ||
713 | </t> | ||
714 | <figure anchor="figure_rdata"> | ||
715 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
716 | 0 8 16 24 32 40 48 56 | ||
717 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
718 | | RR COUNT | EXPIRA- / | ||
719 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
720 | / -TION | DATA SIZE | | ||
721 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
722 | | TYPE | FLAGS | | ||
723 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
724 | | DATA / | ||
725 | / / | ||
726 | / | | ||
727 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
728 | | EXPIRATION | | ||
729 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
730 | | DATA SIZE | TYPE | | ||
731 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
732 | | FLAGS | DATA / | ||
733 | +-----+-----+-----+-----+ / | ||
734 | / +-----------------------/ | ||
735 | / | / | ||
736 | +-----------------------+ / | ||
737 | / PADDING / | ||
738 | / / | ||
739 | ]]></artwork> | ||
740 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
741 | </figure> | ||
742 | <t>where:</t> | ||
743 | <dl> | ||
744 | <dt>RR COUNT</dt> | ||
745 | <dd> | ||
746 | A 32-bit value containing the number of variable-length resource | ||
747 | records which are | ||
748 | following after this field in network byte order. | ||
749 | </dd> | ||
750 | <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt> | ||
751 | <dd> | ||
752 | These fields were defined | ||
753 | in the resource record format in <xref target="rrecords" />. | ||
754 | There MUST be a total of RR COUNT of these resource records | ||
755 | present. | ||
756 | </dd> | ||
757 | <dt>PADDING</dt> | ||
758 | <dd> | ||
759 | The padding MUST contain the value 0 in all octets. | ||
760 | The padding MUST ensure that the size of the RDATA WITHOUT the RR | ||
761 | COUNT field is a power of two. | ||
762 | As a special exception, record sets with (only) a PKEY record type | ||
763 | are never padded. Note that a record set with a PKEY record MUST NOT | ||
764 | contain other records. | ||
765 | </dd> | ||
766 | |||
767 | </dl> | ||
768 | <t> | ||
769 | The symmetric keys and initialization vectors are derived from the | ||
770 | record label and the zone key "zk". For decryption of the resource | ||
771 | records block payload, the key material "K" and initialization vector | ||
772 | "IV" for the symmetric cipher are derived as follows: | ||
773 | </t> | ||
774 | <!-- OLD VERSION | ||
775 | PRK_kiv := HKDF-Extract (zk, label) | ||
776 | K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8); | ||
777 | IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8) | ||
778 | --> | ||
779 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
780 | PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) | ||
781 | PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk) | ||
782 | K := HKDF-Expand (PRK_k, label, 512 / 8); | ||
783 | IV := HKDF-Expand (PRK_iv, label, 256 / 8) | ||
784 | ]]></artwork> | ||
785 | <t> | ||
786 | HKDF is a hash-based key derivation function as defined in | ||
787 | <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the | ||
788 | extraction phase and HMAC-SHA256 for the expansion phase. | ||
789 | The output keying material is 64 octets (512 bit) for the symmetric | ||
790 | keys and 32 octets (256 bit) for the initialization vectors. | ||
791 | We divide the resulting keying material "K" into a 256-bit AES | ||
792 | <xref target="RFC3826" /> key | ||
793 | and a 256-bit TWOFISH <xref target="TWOFISH" /> key: | ||
794 | </t> | ||
795 | <figure anchor="figure_hkdf_keys"> | ||
796 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
797 | 0 8 16 24 32 40 48 56 | ||
798 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
799 | | AES KEY | | ||
800 | | | | ||
801 | | | | ||
802 | | | | ||
803 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
804 | | TWOFISH KEY | | ||
805 | | | | ||
806 | | | | ||
807 | | | | ||
808 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
809 | ]]></artwork> | ||
810 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
811 | </figure> | ||
812 | <t> | ||
813 | Similarly, we divide "IV" into a 128-bit initialization vector | ||
814 | and a 128-bit initialization vector: | ||
815 | </t> | ||
816 | <figure anchor="figure_hkdf_ivs"> | ||
817 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
818 | 0 8 16 24 32 40 48 56 | ||
819 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
820 | | AES IV | | ||
821 | | | | ||
822 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
823 | | TWOFISH IV | | ||
824 | | | | ||
825 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
826 | ]]></artwork> | ||
827 | <!-- <postamble>which is a very simple example.</postamble>--> | ||
828 | </figure> | ||
829 | |||
830 | <t> | ||
831 | The keys and IVs are used for a CFB128-AES-256 and | ||
832 | CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in | ||
833 | Cipher FeedBack (CFB) mode <xref target="RFC3826" />. | ||
834 | </t> | ||
835 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
836 | RDATA := AES(K[0:31], IV[0:15], | ||
837 | TWOFISH(K[32:63], IV[16:31], BDATA)) | ||
838 | BDATA := TWOFISH(K[32:63], IV[16:31], | ||
839 | AES(K[0:31], IV[0:15], RDATA)) | ||
840 | ]]></artwork> | ||
841 | </section> | ||
842 | </section> | ||
843 | <section anchor="encoding" numbered="true" toc="default"> | ||
844 | <name>Internationalization and Character Encoding</name> | ||
845 | <t> | ||
846 | All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />. | ||
847 | This does not include any DNS names found in DNS records, such as CNAME | ||
848 | records, which are internationalized through the IDNA specifications | ||
849 | <xref target="RFC5890" />. | ||
850 | </t> | ||
851 | </section> | ||
852 | <section anchor="resolution" numbered="true" toc="default"> | ||
853 | <name>Name Resolution</name> | ||
854 | <t> | ||
855 | Names in GNS are resolved by recursively querying the DHT record storage. | ||
856 | In the following, we define how resolution is initiated and each | ||
857 | iteration in the resolution is processed. | ||
858 | </t> | ||
859 | <t> | ||
860 | GNS resolution of a name must start in a given starting zone indicated using | ||
861 | a zone public key. | ||
862 | Details on how the starting zone may be determined is discussed in | ||
863 | <xref target="governance" />. | ||
864 | </t> | ||
865 | <t> | ||
866 | When GNS name resolution is requested, a desired record type MAY be | ||
867 | provided by the client. | ||
868 | The GNS resolver will use the desired record type to guide | ||
869 | processing, for example by providing conversion of VPN records to A | ||
870 | or AAAA records, if that is desired. | ||
871 | |||
872 | However, filtering of record sets according to the required record | ||
873 | types MUST still be done by the client after the resource record set | ||
874 | is retrieved. | ||
875 | </t> | ||
876 | <section anchor="recursion" numbered="true" toc="default"> | ||
877 | <name>Recursion</name> | ||
878 | <t> | ||
879 | In each step of the recursive name resolution, there is an | ||
880 | authoritative zone zk and a name to resolve. The name may be empty. | ||
881 | Initially, the authoritative zone is the start zone. If the name | ||
882 | is empty, it is interpreted as the apex label "@". | ||
883 | </t> | ||
884 | <t> | ||
885 | From here, the following steps are recursively executed, in order: | ||
886 | </t> | ||
887 | <ol> | ||
888 | <li>Extract the right-most label from the name to look up.</li> | ||
889 | <li>Calculate q using the label and zk as defined in | ||
890 | <xref target="blinding" />.</li> | ||
891 | <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li> | ||
892 | <li>Verify and process the RRBLOCK and decrypt the BDATA contained | ||
893 | in it as defined in <xref target="recordencryption" />.</li> | ||
894 | </ol> | ||
895 | <t> | ||
896 | Upon receiving the RRBLOCK from the DHT, apart from verifying the | ||
897 | provided signature, the resolver MUST check that the authoritative | ||
898 | zone key was used to sign the record: | ||
899 | The derived zone key "h*zk" MUST match the public key provided in | ||
900 | the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT lookup | ||
901 | GET(q) MUST continue. | ||
902 | </t> | ||
903 | </section> | ||
904 | <section anchor="record_processing" numbered="true" toc="default"> | ||
905 | <name>Record Processing</name> | ||
906 | <t> | ||
907 | Record processing occurs at the end of a single recursion. We assume | ||
908 | that the RRBLOCK has been cryptographically verified and decrypted. | ||
909 | At this point, we must first determine if we have received a valid | ||
910 | record set in the context of the name we are trying to resolve: | ||
911 | </t> | ||
912 | <ol> | ||
913 | <li> | ||
914 | Case 1: | ||
915 | If the remainder of the name to resolve is empty and the record set | ||
916 | does not consist of a PKEY, CNAME or DNS2GNS record, the record set | ||
917 | is the result and the recursion is concluded. | ||
918 | </li> | ||
919 | <li> | ||
920 | Case 2: | ||
921 | If the name to be resolved is of the format | ||
922 | "_SERVICE._PROTO" and the record set contains one or more matching BOX | ||
923 | records, the records in the BOX records are the result and the recusion | ||
924 | is concluded (<xref target="box_processing" />). | ||
925 | </li> | ||
926 | <li> | ||
927 | Case 3: | ||
928 | If the remainder of the name to resolve is not empty and | ||
929 | does not match the "_SERVICE._PROTO" syntax, then the current record set | ||
930 | MUST consist of a single PKEY record (<xref target="pkey_processing" />), | ||
931 | a single CNAME record (<xref target="cname_processing" />), | ||
932 | or one or more GNS2DNS records (<xref target="gns2dns_processing" />), | ||
933 | which are processed as described in the respective sections below. | ||
934 | The record set may include any number of supplemental records. | ||
935 | Otherwise, resolution fails | ||
936 | and the resolver MUST return an empty record set. | ||
937 | |||
938 | Finally, after the recursion terminates, the client preferences | ||
939 | for the record type SHOULD be considered. If a VPN record is found | ||
940 | and the client requests an A or AAAA record, the VPN record | ||
941 | SHOULD be converted (<xref target="vpn_processing" />) | ||
942 | if possible. | ||
943 | </li> | ||
944 | </ol> | ||
945 | <section anchor="pkey_processing" numbered="true" toc="default"> | ||
946 | <name>PKEY</name> | ||
947 | <t> | ||
948 | When the resolver encounters a PKEY record and the remainder of | ||
949 | the name is not empty, resolution continues | ||
950 | recursively with the remainder of the name in the | ||
951 | GNS zone specified in the PKEY record. | ||
952 | </t> | ||
953 | <t> | ||
954 | If the remainder of the name to resolve is empty and we have | ||
955 | received a record set containing only a single PKEY record, the | ||
956 | recursion is continued with the PKEY as authoritative zone and | ||
957 | the empty apex label "@" as remaining name, except in the case | ||
958 | where the desired record type is PKEY, in which case the PKEY | ||
959 | record is returned and the resolution is concluded without | ||
960 | resolving the empty apex label. | ||
961 | </t> | ||
962 | </section> | ||
963 | <section anchor="gns2dns_processing" numbered="true" toc="default"> | ||
964 | <name>GNS2DNS</name> | ||
965 | <t> | ||
966 | When a resolver encounters one or more GNS2DNS records and the remaining name | ||
967 | is empty and the desired record type is GNS2DNS, the GNS2DNS | ||
968 | records are returned. | ||
969 | </t> | ||
970 | <t> | ||
971 | Otherwise, it is expected that the resolver first resolves the | ||
972 | IP(s) of the specified DNS name server(s). GNS2DNS records MAY | ||
973 | contain numeric IPv4 or IPv6 addresses, allowing the resolver to | ||
974 | skip this step. | ||
975 | The DNS server names may themselves be names in GNS or DNS. | ||
976 | If the DNS server name ends in ".+", the rest of the name is to be | ||
977 | interpreted relative to the zone of the GNS2DNS record. | ||
978 | If the DNS server name ends in ".<Base32(zk)>", the DNS | ||
979 | server name is to be resolved against the GNS zone zk. | ||
980 | </t> | ||
981 | <t> | ||
982 | Multiple GNS2DNS records may be stored under the same label, | ||
983 | in which case the resolver MUST try all of them. | ||
984 | The resolver MAY try them in any order or even in parallel. | ||
985 | If multiple GNS2DNS records are present, the DNS name MUST be | ||
986 | identical for all of them, if not the resolution fails and an | ||
987 | emtpy record set is returned as the record set is invalid. | ||
988 | </t> | ||
989 | <t> | ||
990 | Once the IP addresses of the DNS servers have been determined, | ||
991 | the DNS name from the GNS2DNS record is appended | ||
992 | to the remainder of the name to be resolved, and | ||
993 | resolved by querying the DNS name server(s). As the DNS servers | ||
994 | specified are possibly authoritative DNS servers, the GNS resolver MUST | ||
995 | support recursive resolution and MUST NOT delegate this to the | ||
996 | authoritative DNS servers. | ||
997 | The first successful recursive name resolution result | ||
998 | is returned to the client. | ||
999 | In addition, the resolver returns the queried DNS name as a | ||
1000 | supplemental LEHO record (<xref target="gnsrecords_leho" />) with a | ||
1001 | relative expiration time of one hour. | ||
1002 | </t> | ||
1003 | <t> | ||
1004 | GNS resolvers SHOULD offer a configuration | ||
1005 | option to disable DNS processing to avoid information leakage | ||
1006 | and provide a consistent security profile for all name resolutions. | ||
1007 | Such resolvers would return an empty record set upon encountering | ||
1008 | a GNS2DNS record during the recursion. However, if GNS2DNS records | ||
1009 | are encountered in the record set for the apex and a GNS2DNS record | ||
1010 | is expicitly requested by the application, such records MUST | ||
1011 | still be returned, even if DNS support is disabled by the | ||
1012 | GNS resolver configuration. | ||
1013 | </t> | ||
1014 | </section> | ||
1015 | <section anchor="cname_processing" numbered="true" toc="default"> | ||
1016 | <name>CNAME</name> | ||
1017 | <t> | ||
1018 | If a CNAME record is encountered, the canonical name is | ||
1019 | appended to the remaining name, except if the remaining name | ||
1020 | is empty and the desired record type is CNAME, in which case | ||
1021 | the resolution concludes with the CNAME record. | ||
1022 | If the canonical name ends in ".+", | ||
1023 | resolution continues in GNS with the new name in the | ||
1024 | current zone. Otherwise, the resulting name is resolved via the | ||
1025 | default operating system name resolution process. | ||
1026 | This may in turn again trigger a GNS resolution process depending | ||
1027 | on the system configuration. | ||
1028 | <!-- Note: this permits non-DNS resolvers to be triggered via NSS! --> | ||
1029 | </t> | ||
1030 | <t> | ||
1031 | The recursive DNS resolution process may yield a CNAME as well | ||
1032 | which in turn may either point into the DNS or GNS namespace | ||
1033 | (if it ends in a ".<Base32(zk)>"). | ||
1034 | In order to prevent infinite loops, the resolver MUST | ||
1035 | implement loop detections or limit the number of recursive | ||
1036 | resolution steps. | ||
1037 | If the last CNAME was a DNS name, the resolver returns the DNS name | ||
1038 | as a supplemental LEHO record (<xref target="gnsrecords_leho" />) | ||
1039 | with a relative expiration time of one hour. | ||
1040 | <!-- Note: Martin: do we actually implement this in GNS today? | ||
1041 | Seems rather tricky to detect if we go via NSS... --> | ||
1042 | </t> | ||
1043 | </section> | ||
1044 | <section anchor="box_processing" numbered="true" toc="default"> | ||
1045 | <name>BOX</name> | ||
1046 | <t> | ||
1047 | When a BOX record is received, a GNS resolver must unbox it if the | ||
1048 | name to be resolved continues with "_SERVICE._PROTO". | ||
1049 | Otherwise, the BOX record is to be left untouched. This way, TLSA | ||
1050 | (and SRV) records do not require a separate network request, and | ||
1051 | TLSA records become inseparable from the corresponding address | ||
1052 | records. | ||
1053 | </t> | ||
1054 | </section> | ||
1055 | <section anchor="vpn_processing" numbered="true" toc="default"> | ||
1056 | <name>VPN</name> | ||
1057 | <t> | ||
1058 | At the end of the recursion, | ||
1059 | if the queried record type is either A or AAAA and the retrieved | ||
1060 | record set contains at least one VPN record, the resolver SHOULD | ||
1061 | open a tunnel and return the IPv4 or IPv6 tunnel address, | ||
1062 | respectively. | ||
1063 | The type of tunnel depends on the contents of the VPN record data. | ||
1064 | The VPN record MUST be returned if the resolver implementation | ||
1065 | does not support setting up a tunnnel. | ||
1066 | </t> | ||
1067 | </section> | ||
1068 | <section anchor="nick_processing" numbered="true" toc="default"> | ||
1069 | <name>NICK</name> | ||
1070 | <t> | ||
1071 | NICK records are only relevant to the recursive resolver | ||
1072 | if the record set in question is the final result which is to | ||
1073 | be returned to the client. The encountered NICK records may either | ||
1074 | be supplemental (see <xref target="rrecords"/>) or | ||
1075 | non-supplemental. | ||
1076 | If the NICK record is supplemental, the resolver only returns the | ||
1077 | record set if one of the non-supplemental records matches the | ||
1078 | queried record type. | ||
1079 | </t> | ||
1080 | <t> | ||
1081 | The differentiation between a supplemental and non-supplemental | ||
1082 | NICK record allows the client to match the record to the | ||
1083 | authoritative zone. Consider the following example: | ||
1084 | </t> | ||
1085 | <figure> | ||
1086 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1087 | Query: alice.example (type=A) | ||
1088 | Result: | ||
1089 | A: 192.0.2.1 | ||
1090 | NICK: eve | ||
1091 | ]]></artwork> | ||
1092 | </figure> | ||
1093 | <t> | ||
1094 | In this example, the returned NICK record is non-supplemental. | ||
1095 | For the client, this means that the NICK belongs to the zone | ||
1096 | "alice.doe" and is published under the empty label along with an A | ||
1097 | record. The NICK record should be interpreted as: The zone defined by | ||
1098 | "alice.doe" wants to be referred to as "eve". | ||
1099 | In contrast, consider the following: | ||
1100 | </t> | ||
1101 | <figure> | ||
1102 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1103 | Query: alice.example (type=AAAA) | ||
1104 | Result: | ||
1105 | AAAA: 2001:DB8::1 | ||
1106 | NICK: john (Supplemental) | ||
1107 | ]]></artwork> | ||
1108 | </figure> | ||
1109 | <t> | ||
1110 | In this case, the NICK record is marked as supplemental. This means that | ||
1111 | the NICK record belongs to the zone "doe" and is published under the | ||
1112 | label "alice" along with an A record. The NICK record should be | ||
1113 | interpreted as: The zone defined by "doe" wants to be referred to as | ||
1114 | "john". This distinction is likely useful for other records published as | ||
1115 | supplemental. | ||
1116 | </t> | ||
1117 | |||
1118 | |||
1119 | </section> | ||
1120 | </section> | ||
1121 | </section> | ||
1122 | <section anchor="revocation" numbered="true" toc="default"> | ||
1123 | <name>Zone Revocation</name> | ||
1124 | <t> | ||
1125 | Whenever a recursive resolver encounters a new GNS zone, it MUST | ||
1126 | check against the local revocation list whether the respective | ||
1127 | zone key has been revoked. If the zone key was revoked, the | ||
1128 | resolution MUST fail with an empty result set. | ||
1129 | </t> | ||
1130 | <t> | ||
1131 | In order to revoke a zone key, a signed revocation object SHOULD be | ||
1132 | published. | ||
1133 | This object MUST be signed using the private zone key. | ||
1134 | The revocation object is flooded in the overlay network. To prevent | ||
1135 | flooding attacks, the revocation message MUST contain a proof of work | ||
1136 | (PoW). | ||
1137 | The revocation message including the PoW MAY be calculated | ||
1138 | ahead of time to support timely revocation. | ||
1139 | </t> | ||
1140 | <t> | ||
1141 | For all occurences below, "Argon2id" is the Password-based Key | ||
1142 | Derivation Function as defined in <xref target="Argon2" />. For the | ||
1143 | PoW calculations the algorithm is instantiated with the | ||
1144 | following parameters: | ||
1145 | </t> | ||
1146 | <dl> | ||
1147 | <dt>S</dt> | ||
1148 | <dd>The salt. Fixed 16-octet string: "GnsRevocationPow".</dd> | ||
1149 | <dt>t</dt> | ||
1150 | <dd>Number of iterations: 3</dd> | ||
1151 | <dt>m</dt> | ||
1152 | <dd>Memory size in KiB: 1024</dd> | ||
1153 | <dt>T</dt> | ||
1154 | <dd>Output length of hash in bytes: 64</dd> | ||
1155 | <dt>p</dt> | ||
1156 | <dd>Parallelization parameter: 1</dd> | ||
1157 | <dt>v</dt> | ||
1158 | <dd>Algorithm version: 0x13</dd> | ||
1159 | <dt>y</dt> | ||
1160 | <dd>Algorithm type (Argon2id): 2</dd> | ||
1161 | <dt>X</dt><dd>Unused</dd> | ||
1162 | <dt>K</dt><dd>Unused</dd> | ||
1163 | </dl> | ||
1164 | <t> | ||
1165 | The following is the message string "P" on which the PoW is | ||
1166 | calculated: | ||
1167 | </t> | ||
1168 | <figure anchor="figure_revocation"> | ||
1169 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1170 | 0 8 16 24 32 40 48 56 | ||
1171 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1172 | | POW | | ||
1173 | +-----------------------------------------------+ | ||
1174 | | TIMESTAMP | | ||
1175 | +-----------------------------------------------+ | ||
1176 | | PUBLIC KEY | | ||
1177 | | | | ||
1178 | | | | ||
1179 | | | | ||
1180 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1181 | ]]></artwork> | ||
1182 | </figure> | ||
1183 | <t>where:</t> | ||
1184 | <dl> | ||
1185 | <dt>POW</dt> | ||
1186 | <dd> | ||
1187 | A 64-bit solution to the PoW. In network byte order. | ||
1188 | </dd> | ||
1189 | <dt>TIMESTAMP</dt> | ||
1190 | <dd> | ||
1191 | denotes the absolute 64-bit date when the revocation was computed. | ||
1192 | In microseconds since midnight (0 hour), January 1, 1970 in network | ||
1193 | byte order. | ||
1194 | </dd> | ||
1195 | <dt>PUBLIC KEY</dt> | ||
1196 | <dd> | ||
1197 | is the 256-bit public key "zk" of the zone which is being revoked and | ||
1198 | the key to be used to verify SIGNATURE. The | ||
1199 | wire format of this value is defined in <xref target="RFC8032" />, | ||
1200 | Section 5.1.5. | ||
1201 | </dd> | ||
1202 | </dl> | ||
1203 | <t> | ||
1204 | Traditionally, PoW schemes require to find a "POW" such that | ||
1205 | at least D leading zeroes are found in the hash result. | ||
1206 | D is then referred to as the "difficulty" of the PoW. | ||
1207 | In order to reduce the variance in time it takes to calculate the | ||
1208 | PoW, we require that a number "Z" different PoWs must be | ||
1209 | found that on average have "D" leading zeroes. | ||
1210 | </t> | ||
1211 | <t> | ||
1212 | The resulting proofs may then published and disseminated. The concrete | ||
1213 | dissemination and publication methods are out of scope of this | ||
1214 | document. Given an average difficulty of "D", the proofs have an | ||
1215 | expiration time of EPOCH. With each additional bit difficulty, the | ||
1216 | lifetime of the proof is prolonged for another EPOCH. | ||
1217 | Consequently, by calculating a more difficult PoW, the lifetime of the | ||
1218 | proof can be increased on demand by the zone owner. | ||
1219 | </t> | ||
1220 | <t> | ||
1221 | The parameters are defined as follows: | ||
1222 | </t> | ||
1223 | <dl> | ||
1224 | <dt>Z</dt> | ||
1225 | <dd>The number of PoWs required is fixed at 32.</dd> | ||
1226 | <dt>D</dt> | ||
1227 | <dd>The difficulty is fixed at 25.</dd> | ||
1228 | <dt>EPOCH</dt> | ||
1229 | <dd>A single epoch is fixed at 365 days.</dd> | ||
1230 | </dl> | ||
1231 | <t> | ||
1232 | Given that proof has been found, a revocation data object is defined | ||
1233 | as follows: | ||
1234 | </t> | ||
1235 | <figure anchor="figure_revocationdata"> | ||
1236 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1237 | 0 8 16 24 32 40 48 56 | ||
1238 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1239 | | TIMESTAMP | | ||
1240 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1241 | | TTL | | ||
1242 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1243 | | POW_0 | | ||
1244 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1245 | | ... | | ||
1246 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1247 | | POW_Z-1 | | ||
1248 | +-----------------------------------------------+ | ||
1249 | | SIGNATURE | | ||
1250 | | | | ||
1251 | | | | ||
1252 | | | | ||
1253 | | | | ||
1254 | | | | ||
1255 | | | | ||
1256 | | | | ||
1257 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1258 | | PUBLIC KEY | | ||
1259 | | | | ||
1260 | | | | ||
1261 | | | | ||
1262 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1263 | ]]></artwork> | ||
1264 | </figure> | ||
1265 | <t>where:</t> | ||
1266 | <dl> | ||
1267 | <dt>TIMESTAMP</dt> | ||
1268 | <dd> | ||
1269 | denotes the absolute 64-bit date when the revocation was computed. | ||
1270 | In microseconds since midnight (0 hour), January 1, 1970 in network | ||
1271 | byte order. This is the same value as the timestamp used in the | ||
1272 | individual PoW calculations. | ||
1273 | </dd> | ||
1274 | <dt>TTL</dt> | ||
1275 | <dd> | ||
1276 | denotes the relative 64-bit time to live of of the record in | ||
1277 | microseconds also in network byte order. This field is informational | ||
1278 | for a verifier. The verifier may discard revocation if the TTL | ||
1279 | indicates that it is already expired. However, the actual TTL of the | ||
1280 | revocation must be determined by examining the leading zeros in the | ||
1281 | proof of work calculation. | ||
1282 | </dd> | ||
1283 | <dt>POW_i</dt> | ||
1284 | <dd> | ||
1285 | The values calculated as part of the PoW, in network byte order. | ||
1286 | Each POW_i MUST be unique in the set of POW values. | ||
1287 | To facilitate fast verification | ||
1288 | of uniqueness, the POW values must be given in strictly | ||
1289 | monotonically increasing order in the message. | ||
1290 | </dd> | ||
1291 | <dt>SIGNATURE</dt> | ||
1292 | <dd> | ||
1293 | A 512-bit ECDSA deterministic signature compliant with | ||
1294 | <xref target="RFC6979" /> over the public zone zk of the zone | ||
1295 | which is revoked and corresponds to the key used in the PoW. | ||
1296 | The signature is created using the private zone key "d" (see | ||
1297 | <xref target="zones" />). | ||
1298 | </dd> | ||
1299 | <dt>PUBLIC KEY</dt> | ||
1300 | <dd> | ||
1301 | is the 256-bit public key "zk" of the zone which is being revoked and | ||
1302 | the key to be used to verify SIGNATURE. The | ||
1303 | wire format of this value is defined in <xref target="RFC8032" />, | ||
1304 | Section 5.1.5. | ||
1305 | </dd> | ||
1306 | </dl> | ||
1307 | <t> | ||
1308 | The signature over the public key covers a 32 bit pseudo header | ||
1309 | conceptually prefixed to the public key. The pseudo header includes | ||
1310 | the key length and signature purpose: | ||
1311 | </t> | ||
1312 | <figure anchor="figure_revsigwithpseudo"> | ||
1313 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1314 | 0 8 16 24 32 40 48 56 | ||
1315 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1316 | | SIZE (0x30) | PURPOSE (0x03) | | ||
1317 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1318 | | PUBLIC KEY | | ||
1319 | | | | ||
1320 | | | | ||
1321 | | | | ||
1322 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1323 | | TIMESTAMP | | ||
1324 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ||
1325 | ]]></artwork> | ||
1326 | </figure> | ||
1327 | <t>where:</t> | ||
1328 | <dl> | ||
1329 | <dt>SIZE</dt> | ||
1330 | <dd> | ||
1331 | A 32-bit value containing the length of the signed data in bytes | ||
1332 | (48 bytes) in network byte order. | ||
1333 | </dd> | ||
1334 | <dt>PURPOSE</dt> | ||
1335 | <dd> | ||
1336 | A 32-bit signature purpose flag. This field MUST be 3 (in network | ||
1337 | byte order). | ||
1338 | </dd> | ||
1339 | <dt>PUBLIC KEY / TIMESTAMP</dt> | ||
1340 | <dd>Both values as defined in the revocation data object above.</dd> | ||
1341 | </dl> | ||
1342 | <t> | ||
1343 | In order to verify a revocation the following steps must be taken, | ||
1344 | in order: | ||
1345 | </t> | ||
1346 | <ol> | ||
1347 | <li>The current time MUST be between TIMESTAMP and | ||
1348 | TIMESTAMP+TTL.</li> | ||
1349 | <li>The signature MUST match the public key.</li> | ||
1350 | <li>The set of POW values MUST NOT contain duplicates.</li> | ||
1351 | <li>The average number of leading zeroes resulting from the provided | ||
1352 | POW values D' MUST be greater than D.</li> | ||
1353 | <li>The validation period (TTL) of the revocation is calculated as | ||
1354 | (D'-D) * EPOCH * 1.1. The EPOCH is extended by | ||
1355 | 10% in order to deal with unsynchronized clocks. | ||
1356 | The TTL added on top of the TIMESTAMP yields the | ||
1357 | expiration date.</li> | ||
1358 | </ol> | ||
1359 | </section> | ||
1360 | <section anchor="governance" numbered="true" toc="default"> | ||
1361 | <name>Determining the Root Zone and Zone Governance</name> | ||
1362 | <t> | ||
1363 | The resolution of a GNS name must start in a given start zone | ||
1364 | indicated to the resolver using any public zone key. | ||
1365 | The local resolver may have a local start zone configured/hard-coded | ||
1366 | which points to a local or remote start zone key. | ||
1367 | A resolver client may also determine the start zone from the | ||
1368 | suffix of the name given for resolution or using information | ||
1369 | retrieved out of band. | ||
1370 | The governance model of any zone is at the sole discretion | ||
1371 | of the zone owner. However, the choice of start zone(s) is at the sole | ||
1372 | discretion of the local system administrator or user. | ||
1373 | </t> | ||
1374 | <t> | ||
1375 | This is an important distinguishing factor from the Domain Name System | ||
1376 | where root zone governance is centralized at the Internet Corporation | ||
1377 | for Assigned Names and Numbers (ICANN). | ||
1378 | In DNS terminology, GNS roughly follows the idea of a hyper-hyper | ||
1379 | local root zone deployment, with the difference that it is not | ||
1380 | expected that all deployments use the same local root zone. | ||
1381 | </t> | ||
1382 | <t> | ||
1383 | In the following, we give examples how a local client resolver SHOULD | ||
1384 | discover the start zone. The process given is not exhaustive and | ||
1385 | clients MAY suppliement it with other mechanisms or ignore it if the | ||
1386 | particular application requires a different process. | ||
1387 | </t> | ||
1388 | <t> | ||
1389 | GNS clients SHOULD first try to interpret the top-level domain of | ||
1390 | a GNS name as a zone key. | ||
1391 | For example. if the top-level domain is a Base32-encoded public zone | ||
1392 | key "zk", the root zone of the resolution process is implicitly given | ||
1393 | by the name: | ||
1394 | </t> | ||
1395 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1396 | Example name: www.example.<Base32(zk)> | ||
1397 | => Root zone: zk | ||
1398 | => Name to resolve from root zone: www.example | ||
1399 | ]]></artwork> | ||
1400 | <t> | ||
1401 | In GNS, users MAY own and manage their own zones. | ||
1402 | Each local zone SHOULD be associated with a single GNS label, | ||
1403 | but users MAY choose to use longer names consisting of | ||
1404 | multiple labels. | ||
1405 | If the name of a locally managed zone matches the suffix | ||
1406 | of the name to be resolved, | ||
1407 | resolution SHOULD start from the respective local zone: | ||
1408 | </t> | ||
1409 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1410 | Example name: www.example.org | ||
1411 | Local zones: | ||
1412 | fr = (d0,zk0) | ||
1413 | gnu = (d1,zk1) | ||
1414 | com = (d2,zk2) | ||
1415 | ... | ||
1416 | => Entry zone: zk1 | ||
1417 | => Name to resolve from entry zone: www.example | ||
1418 | ]]></artwork> | ||
1419 | <t> | ||
1420 | Finally, additional "suffix to zone" mappings MAY be configured. | ||
1421 | Suffix to zone key mappings SHOULD be configurable through a local | ||
1422 | configuration file or database by the user or system administrator. | ||
1423 | The suffix MAY consist of multiple GNS labels concatenated with a | ||
1424 | ".". If multiple suffixes match the name to resolve, the longest | ||
1425 | matching suffix MUST BE used. The suffix length of two results | ||
1426 | cannot be equal, as this would indicate a misconfiguration. | ||
1427 | If both a locally managed zone and a configuration entry exist | ||
1428 | for the same suffix, the locally managed zone MUST have priority. | ||
1429 | </t> | ||
1430 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1431 | Example name: www.example.org | ||
1432 | Local suffix mappings: | ||
1433 | gnu = zk0 | ||
1434 | example.org = zk1 | ||
1435 | example.com = zk2 | ||
1436 | ... | ||
1437 | => Entry zone: zk1 | ||
1438 | => Name to resolve from entry zone: www | ||
1439 | ]]></artwork> | ||
1440 | </section> | ||
1441 | <section anchor="security" numbered="true" toc="default"> | ||
1442 | <name>Security Considerations</name> | ||
1443 | <section anchor="security_crypto" numbered="true" toc="default"> | ||
1444 | <name>Cryptography</name> | ||
1445 | <t> | ||
1446 | The security of cryptographic systems depends on both the strength of | ||
1447 | the cryptographic algorithms chosen and the strength of the keys used | ||
1448 | with those algorithms. The security also depends on the engineering | ||
1449 | of the protocol used by the system to ensure that there are no | ||
1450 | non-cryptographic ways to bypass the security of the overall system. | ||
1451 | </t> | ||
1452 | <t> | ||
1453 | This document concerns itself with the selection of cryptographic | ||
1454 | algorithms for use in GNS. | ||
1455 | The algorithms identified in this document are not known to be | ||
1456 | broken (in the cryptographic sense) at the current time, and | ||
1457 | cryptographic research so far leads us to believe that they are | ||
1458 | likely to remain secure into the foreseeable future. However, this | ||
1459 | isn't necessarily forever, and it is expected that new revisions of | ||
1460 | this document will be issued from time to time to reflect the current | ||
1461 | best practices in this area. | ||
1462 | </t> | ||
1463 | <t> | ||
1464 | GNS uses ECDSA over Curve25519. This is an unconventional choice, | ||
1465 | as ECDSA is usually used with other curves. However, traditional | ||
1466 | ECDSA curves are problematic for a range of reasons described in | ||
1467 | the Curve25519 and EdDSA papers. Using EdDSA directly is also | ||
1468 | not possible, as a hash function is used on the private key which | ||
1469 | destroys the linearity that the GNU Name System depends upon. | ||
1470 | We are not aware of anyone suggesting that using Curve25519 instead | ||
1471 | of another common curve of similar size would lower the security of | ||
1472 | ECDSA. GNS uses 256-bit curves because that way the encoded (public) | ||
1473 | keys fit into a single DNS label, which is good for usability. | ||
1474 | </t> | ||
1475 | <t> | ||
1476 | In terms of crypto-agility, whenever the need for an updated cryptographic | ||
1477 | scheme arises to replace ECDSA over Curve25519 it may simply be introduced | ||
1478 | through a new record type. Such a new record type may then replace | ||
1479 | the PKEY record type for future records. The old record type remains | ||
1480 | and zones can iteratively migrate to the updated zone keys. | ||
1481 | </t> | ||
1482 | </section> | ||
1483 | <section anchor="security_abuse" numbered="true" toc="default"> | ||
1484 | <name>Abuse mitigation</name> | ||
1485 | <t> | ||
1486 | GNS names are UTF-8 strings. Consequently, GNS faces similar issues | ||
1487 | with respect to name spoofing as DNS does for internationalized | ||
1488 | domain names. | ||
1489 | In DNS, attackers may register similar sounding or looking | ||
1490 | names (see above) in order to execute phishing attacks. | ||
1491 | GNS zone administrators must take into account this attack vector and | ||
1492 | incorporate rules in order to mitigate it. | ||
1493 | </t> | ||
1494 | <t> | ||
1495 | Further, DNS can be used to combat illegal content on the internet | ||
1496 | by having the respective domains seized by authorities. | ||
1497 | However, the same mechanisms can also be abused in order to impose | ||
1498 | state censorship, which ist one of the motivations behind GNS. | ||
1499 | Hence, such a seizure is, by design, difficult to impossible in GNS. | ||
1500 | In particular, GNS does not support WHOIS (<xref target="RFC3912" />). | ||
1501 | </t> | ||
1502 | </section> | ||
1503 | <section anchor="security_keymanagement" numbered="true" toc="default"> | ||
1504 | <name>Zone management</name> | ||
1505 | <t> | ||
1506 | In GNS, zone administrators need to manage and protect their zone | ||
1507 | keys. Once a zone key is lost it cannot be recovered. Once it is | ||
1508 | compromised it cannot be revoked (unless a revocation message was | ||
1509 | pre-calculated and is still available). | ||
1510 | Zone administrators, and for GNS this includes end-users, are | ||
1511 | required to responsibly and dilligently protect their cryptographic | ||
1512 | keys. Offline signing is in principle possible, but GNS does not | ||
1513 | support separate zone signing and key-signing keys | ||
1514 | (as in <xref target="RFC6781" />) in order to provide usable security. | ||
1515 | </t> | ||
1516 | <t> | ||
1517 | Similarly, users are required to manage their local root zone. | ||
1518 | In order to ensure integrity and availability or names, users must | ||
1519 | ensure that their local root zone information is not compromised or | ||
1520 | outdated. | ||
1521 | It can be expected that the processing of zone revocations and an | ||
1522 | initial root zone is provided with a GNS client implementation | ||
1523 | ("drop shipping"). | ||
1524 | Extension and customization of the zone is at the full discretion of | ||
1525 | the user. | ||
1526 | </t> | ||
1527 | </section> | ||
1528 | <section anchor="security_dht" numbered="true" toc="default"> | ||
1529 | <name>Impact of underlying DHT</name> | ||
1530 | <t> | ||
1531 | This document does not specifiy the properties of the underlying | ||
1532 | distributed hash table (DHT) which is required by any GNS | ||
1533 | implementation. For implementors, it is important to note that | ||
1534 | the properties of the DHT are directly inherited by the | ||
1535 | GNS implementation. This includes both security as well as | ||
1536 | other non-functional properties such as scalability and performance. | ||
1537 | Implementors should take great care when selecting or implementing | ||
1538 | a DHT for use in a GNS implementation. | ||
1539 | DHTs with string security and performance guarantees exist | ||
1540 | <xref target="R5N"/>. | ||
1541 | It should also be taken into consideration that GNS implementations | ||
1542 | which build upon different DHT overlays are unlikely to be | ||
1543 | interoperable with each other. | ||
1544 | </t> | ||
1545 | </section> | ||
1546 | <section anchor="security_rev" numbered="true" toc="default"> | ||
1547 | <name>Revocations</name> | ||
1548 | <t> | ||
1549 | Zone administrators are advised to pre-generate zone revocations | ||
1550 | and securely store the revocation information in case the zone | ||
1551 | key is lost, compromised or replaced in the furture. | ||
1552 | Pre-calculated revocations may become invalid due to expirations | ||
1553 | or protocol changes such as epoch adjustments. | ||
1554 | Consequently, implementors and users must make precautions in order | ||
1555 | to manage revocations accordingly. | ||
1556 | </t> | ||
1557 | <t> | ||
1558 | Revocation payloads do NOT include a 'new' key for key replacement. | ||
1559 | Inclusion of such a key would have two major disadvantages: | ||
1560 | </t> | ||
1561 | <t> | ||
1562 | If revocation is used after a private key was compromised, | ||
1563 | allowing key replacement would be dangerous: if an | ||
1564 | adversary took over the private key, the adversary could then | ||
1565 | broadcast a revocation with a key replacement. For the replacement, | ||
1566 | the compromised owner would have no chance to issue even a | ||
1567 | revocation. Thus, allowing a revocation message to replace a private | ||
1568 | key makes dealing with key compromise situations worse. | ||
1569 | </t> | ||
1570 | <t> | ||
1571 | Sometimes, key revocations are used with the objective of changing | ||
1572 | cryptosystems. Migration to another cryptosystem by replacing keys | ||
1573 | via a revocation message would only be secure as long as both | ||
1574 | cryptosystems are still secure against forgery. Such a planned, | ||
1575 | non-emergency migration to another cryptosystem should be done by | ||
1576 | running zones for both ciphersystems in parallel for a while. The | ||
1577 | migration would conclude by revoking the legacy zone key only once | ||
1578 | it is deemed no longer secure, and hopefully after most users have | ||
1579 | migrated to the replacement. | ||
1580 | </t> | ||
1581 | </section> | ||
1582 | </section> | ||
1583 | <section anchor="gana" numbered="true" toc="default"> | ||
1584 | <name>GANA Considerations</name> | ||
1585 | <t> | ||
1586 | GANA is requested to create an "GNU Name System Record Types" registry. | ||
1587 | The registry shall record for each entry: | ||
1588 | </t> | ||
1589 | <ul> | ||
1590 | <li>Name: The name of the record type (case-insensitive ASCII | ||
1591 | string, restricted to alphanumeric characters</li> | ||
1592 | <li>Number: 32-bit, above 65535</li> | ||
1593 | <li>Comment: Optionally, a brief English text describing the purpose of | ||
1594 | the record type (in UTF-8)</li> | ||
1595 | <li>Contact: Optionally, the contact information of a person to contact for | ||
1596 | further information</li> | ||
1597 | <li>References: Optionally, references describing the record type | ||
1598 | (such as an RFC)</li> | ||
1599 | </ul> | ||
1600 | <t> | ||
1601 | The registration policy for this sub-registry is "First Come First | ||
1602 | Served", as described in <xref target="RFC8126"/>. | ||
1603 | GANA is requested to populate this registry as follows: | ||
1604 | </t> | ||
1605 | <figure anchor="figure_rrtypenums"> | ||
1606 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1607 | Number | Name | Contact | References | Description | ||
1608 | -------+---------+---------+------------+------------------------- | ||
1609 | 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation | ||
1610 | 65537 | NICK | N/A | [This.I-D] | GNS zone nickname | ||
1611 | 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname | ||
1612 | 65539 | VPN | N/A | [This.I-D] | VPN resolution | ||
1613 | 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS | ||
1614 | 65541 | BOX | N/A | [This.I-D] | Boxed record | ||
1615 | ]]></artwork> | ||
1616 | </figure> | ||
1617 | <t> | ||
1618 | GANA is requested to amend the "GNUnet Signature Purpose" registry | ||
1619 | as follows: | ||
1620 | </t> | ||
1621 | <figure anchor="figure_purposenums"> | ||
1622 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1623 | Purpose | Name | References | Description | ||
1624 | --------+-----------------+------------+-------------------------- | ||
1625 | 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation | ||
1626 | 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature | ||
1627 | ]]></artwork> | ||
1628 | </figure> | ||
1629 | </section> | ||
1630 | <!-- gana --> | ||
1631 | <section> | ||
1632 | <name>Test Vectors</name> | ||
1633 | <t> | ||
1634 | The following represents a test vector for a record set with a DNS | ||
1635 | record of type "A" as well as a GNS record of type "PKEY" | ||
1636 | under the label "test". | ||
1637 | </t> | ||
1638 | <artwork name="" type="" align="left" alt=""> | ||
1639 | <![CDATA[ | ||
1640 | Zone private key (d, little-endian scalar): | ||
1641 | 3015471ecb45455b5e9df50ff416b3d53aa6db6cafec858449f788142d091d41 | ||
1642 | |||
1643 | Zone public key (zk): | ||
1644 | bf06e687a291a509b6326bb6394dd6ed3ff9e5eb78ea5752ed0eba0807023a33 | ||
1645 | |||
1646 | Label: test | ||
1647 | RRCOUNT: 2 | ||
1648 | |||
1649 | Record #0 | ||
1650 | EXPIRATION: 1590482415557079 | ||
1651 | DATA_SIZE: 4 | ||
1652 | TYPE: 1 | ||
1653 | FLAGS: 0 | ||
1654 | DATA: | ||
1655 | 01020304 | ||
1656 | |||
1657 | Record #1 | ||
1658 | EXPIRATION: 1590482415557079 | ||
1659 | DATA_SIZE: 32 | ||
1660 | TYPE: 65536 | ||
1661 | FLAGS: 2 | ||
1662 | DATA: | ||
1663 | 814fbb06b17f4ecf | ||
1664 | d098700619179f9d | ||
1665 | 4aef24465bd6958a | ||
1666 | e4ed01cd024b1856 | ||
1667 | |||
1668 | RDATA: | ||
1669 | 0005a6890b6699d7 | ||
1670 | 0000000400000001 | ||
1671 | 0000000001020304 | ||
1672 | 0005a6890b6699d7 | ||
1673 | 0000002000010000 | ||
1674 | 00000002814fbb06 | ||
1675 | b17f4ecfd0987006 | ||
1676 | 19179f9d4aef2446 | ||
1677 | 5bd6958ae4ed01cd | ||
1678 | 024b185600000000 | ||
1679 | 0000000000000000 | ||
1680 | 0000000000000000 | ||
1681 | 0000000000000000 | ||
1682 | 0000000000000000 | ||
1683 | 0000000000000000 | ||
1684 | 0000000000000000 | ||
1685 | |||
1686 | BDATA: | ||
1687 | 9f471611a5c06fc2 | ||
1688 | c9ad33f642dd315c | ||
1689 | f8fc675aed23e8a1 | ||
1690 | d19a5bad657557fe | ||
1691 | 6e1d50709860593e | ||
1692 | 5376c30f6f22daac | ||
1693 | 5293986b7444476d | ||
1694 | b8f289f5537da168 | ||
1695 | dc81cba256d8401b | ||
1696 | 642dbe6a24346e11 | ||
1697 | 9148ade8acb4d5e5 | ||
1698 | cef5eb5ad1e3b95d | ||
1699 | d143123d387b8df0 | ||
1700 | ba4e2d75a9eb94a4 | ||
1701 | f3250b975fee90e9 | ||
1702 | 558bb9e1e009ca46 | ||
1703 | b7a066dd | ||
1704 | |||
1705 | RRBLOCK: | ||
1706 | 08180a871b910ade | ||
1707 | a1125a1030d0f269 | ||
1708 | 069e5731c90ad0d0 | ||
1709 | cfa10bf61b3f0c79 | ||
1710 | 0833b515d4c746e6 | ||
1711 | 4a7261947bfb6429 | ||
1712 | 21200bb97a96292d | ||
1713 | 6abefab1197f7e4e | ||
1714 | b399c628a71d3627 | ||
1715 | d64a2bd66080f64d | ||
1716 | 91c0120ab14601d8 | ||
1717 | 18de23c8da82b80b | ||
1718 | 000000940000000f | ||
1719 | 0005a6890b6699d7 | ||
1720 | 9f471611a5c06fc2 | ||
1721 | c9ad33f642dd315c | ||
1722 | f8fc675aed23e8a1 | ||
1723 | d19a5bad657557fe | ||
1724 | 6e1d50709860593e | ||
1725 | 5376c30f6f22daac | ||
1726 | 5293986b7444476d | ||
1727 | b8f289f5537da168 | ||
1728 | dc81cba256d8401b | ||
1729 | 642dbe6a24346e11 | ||
1730 | 9148ade8acb4d5e5 | ||
1731 | cef5eb5ad1e3b95d | ||
1732 | d143123d387b8df0 | ||
1733 | ba4e2d75a9eb94a4 | ||
1734 | f3250b975fee90e9 | ||
1735 | 558bb9e1e009ca46 | ||
1736 | b7a066dd | ||
1737 | ]]> | ||
1738 | </artwork> | ||
1739 | <t> | ||
1740 | The following is an example revocation for a zone: | ||
1741 | </t> | ||
1742 | <artwork name="" type="" align="left" alt=""> | ||
1743 | <![CDATA[ | ||
1744 | Zone private key (d, little-endian scalar): | ||
1745 | 90ea2a95cb9ef482b45817dc45b805cae00f387022a065a3674f41ad15173c63 | ||
1746 | |||
1747 | Zone public key (zk): | ||
1748 | 4ac1e51d9a585a9ad9fb0dfac2be100aee83f0cc79c4c5ea8f3eb8afd9092fa5 | ||
1749 | |||
1750 | Difficulty (5 base difficulty + 2 epochs): 7 | ||
1751 | |||
1752 | Proof: | ||
1753 | 0005a5fd368978f4 | ||
1754 | 0000395d1827c000 | ||
1755 | e23f657bc47ec853 | ||
1756 | e23f657bc47ec9d8 | ||
1757 | e23f657bc47ecaec | ||
1758 | e23f657bc47ecb29 | ||
1759 | e23f657bc47ecc00 | ||
1760 | e23f657bc47ecc79 | ||
1761 | e23f657bc47ece83 | ||
1762 | e23f657bc47ecfc6 | ||
1763 | e23f657bc47ecfc8 | ||
1764 | e23f657bc47ecfd5 | ||
1765 | e23f657bc47ed02b | ||
1766 | e23f657bc47ed03b | ||
1767 | e23f657bc47ed0ff | ||
1768 | e23f657bc47ed241 | ||
1769 | e23f657bc47ed264 | ||
1770 | e23f657bc47ed2e5 | ||
1771 | e23f657bc47ed343 | ||
1772 | e23f657bc47ed348 | ||
1773 | e23f657bc47ed45e | ||
1774 | e23f657bc47ed480 | ||
1775 | e23f657bc47ed49a | ||
1776 | e23f657bc47ed564 | ||
1777 | e23f657bc47ed565 | ||
1778 | e23f657bc47ed5b6 | ||
1779 | e23f657bc47ed5de | ||
1780 | e23f657bc47ed5e0 | ||
1781 | e23f657bc47ed77f | ||
1782 | e23f657bc47ed800 | ||
1783 | e23f657bc47ed80c | ||
1784 | e23f657bc47ed817 | ||
1785 | e23f657bc47ed82c | ||
1786 | e23f657bc47ed8a6 | ||
1787 | 0396020c831a5405 | ||
1788 | cee6c38842209191 | ||
1789 | c8db799dbe81e0dc | ||
1790 | f6dbd4f91c257ae2 | ||
1791 | 0079e7fd1cd31cc2 | ||
1792 | 4cd9a52831d5ec30 | ||
1793 | f10e22e5a6dd9065 | ||
1794 | 18746cfce2095610 | ||
1795 | 4ac1e51d9a585a9a | ||
1796 | d9fb0dfac2be100a | ||
1797 | ee83f0cc79c4c5ea | ||
1798 | 8f3eb8afd9092fa5 | ||
1799 | ]]> | ||
1800 | </artwork> | ||
1801 | </section> | ||
1802 | </middle> | ||
1803 | <back> | ||
1804 | <references> | ||
1805 | <name>Normative References</name> | ||
1806 | |||
1807 | &RFC1034; | ||
1808 | &RFC1035; | ||
1809 | &RFC2782; | ||
1810 | &RFC2119; | ||
1811 | &RFC3629; | ||
1812 | &RFC3826; | ||
1813 | &RFC3912; | ||
1814 | &RFC5869; | ||
1815 | &RFC5890; | ||
1816 | &RFC5891; | ||
1817 | &RFC6781; | ||
1818 | &RFC6895; | ||
1819 | &RFC6979; | ||
1820 | &RFC7748; | ||
1821 | &RFC8032; | ||
1822 | &RFC8126; | ||
1823 | |||
1824 | <reference anchor="TWOFISH"> | ||
1825 | <front> | ||
1826 | <title> | ||
1827 | The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition | ||
1828 | </title> | ||
1829 | <author initials="B." surname="Schneier" fullname="B. Schneier"> | ||
1830 | <organization/> | ||
1831 | </author> | ||
1832 | <date year="1999" month="March"/> | ||
1833 | </front> | ||
1834 | </reference> | ||
1835 | <reference anchor="GNS" target="https://doi.org/10.1007/978-3-319-12280-9_9"> | ||
1836 | <front> | ||
1837 | <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title> | ||
1838 | <author initials="M." surname="Wachs" fullname="Matthias Wachs"> | ||
1839 | <organization>Technische Universität München</organization> | ||
1840 | </author> | ||
1841 | |||
1842 | <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"> | ||
1843 | <organization>Technische Universität München</organization> | ||
1844 | </author> | ||
1845 | |||
1846 | <author initials="C." surname="Grothoff" | ||
1847 | fullname="Christian Grothoff"> | ||
1848 | <organization>Technische Universität München</organization> | ||
1849 | </author> | ||
1850 | <date year="2014"/> | ||
1851 | </front> | ||
1852 | </reference> | ||
1853 | <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022"> | ||
1854 | <front> | ||
1855 | <title>R5N: Randomized recursive routing for restricted-route networks</title> | ||
1856 | <author initials="N. S." surname="Evans" fullname="Nathan S. Evans"> | ||
1857 | <organization>Technische Universität München</organization> | ||
1858 | </author> | ||
1859 | |||
1860 | <author initials="C." surname="Grothoff" | ||
1861 | fullname="Christian Grothoff"> | ||
1862 | <organization>Technische Universität München</organization> | ||
1863 | </author> | ||
1864 | <date year="2011"/> | ||
1865 | </front> | ||
1866 | </reference> | ||
1867 | |||
1868 | |||
1869 | <reference anchor="Argon2" target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/"> | ||
1870 | <front> | ||
1871 | <title>The memory-hard Argon2 password hash and proof-of-work function</title> | ||
1872 | <author initials="A." surname="Biryukov" fullname="Alex Biryukov"> | ||
1873 | <organization>University of Luxembourg</organization> | ||
1874 | </author> | ||
1875 | |||
1876 | <author initials="D." surname="Dinu" fullname="Daniel Dinu"> | ||
1877 | <organization>University of Luxembourg</organization> | ||
1878 | </author> | ||
1879 | |||
1880 | <author initials="D." surname="Khovratovich" | ||
1881 | fullname="Dmitry Khovratovich"> | ||
1882 | <organization>ABDK Consulting</organization> | ||
1883 | </author> | ||
1884 | <author initials="S." surname="Josefsson" | ||
1885 | fullname="Simon Josefsson"> | ||
1886 | <organization>SJD AB</organization> | ||
1887 | </author> | ||
1888 | <date year="2020" month="March"/> | ||
1889 | <abstract> | ||
1890 | <t> | ||
1891 | This document describes the Argon2 memory-hard function for | ||
1892 | password hashing and proof-of-work applications. We provide an | ||
1893 | implementer-oriented description with | ||
1894 | test vectors. The purpose is to simplify adoption of Argon2 for | ||
1895 | Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) | ||
1896 | in the IRTF. | ||
1897 | </t> | ||
1898 | </abstract> | ||
1899 | </front> | ||
1900 | </reference> | ||
1901 | <!-- <reference anchor="ISO20022"> | ||
1902 | <front> | ||
1903 | <title>ISO 20022 Financial Services - Universal financial industry message scheme</title> | ||
1904 | <author> | ||
1905 | <organization>International Organization for Standardization</organization> | ||
1906 | <address> | ||
1907 | <uri>http://www.iso.ch</uri> | ||
1908 | </address> | ||
1909 | </author> | ||
1910 | <date month="May" year="2013"/> | ||
1911 | </front> | ||
1912 | </reference>--> | ||
1913 | </references> | ||
1914 | <!-- Change Log | ||
1915 | v00 2017-07-23 MS Initial version | ||
1916 | --> | ||
1917 | </back> | ||
1918 | </rfc> | ||