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