commit a665828bc7566f5d5aed5155eb47a66a235b205f
parent 7e60d7f84371df6e8c4774c86b60182f6624b6ba
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 20:19:28 +0200
add note for punycode for host headers
Diffstat:
3 files changed, 1793 insertions(+), 1664 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1142,12 +1142,41 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">
- This document contains the GNU Name System (GNS) technical specification
- for secure, censorship-resistant and decentralised name resolution.<a href="#section-1-1" class="pilcrow">¶</a></p>
+ The Domain Name System (DNS) is a unique distributed database and a vital
+ service for most Internet applications. While DNS is distributed, it
+ relies on centralized, trusted registrars to provide globally unique
+ names. As the awareness of the central role DNS plays on the Internet
+ rises, various institutions are using their power (including legal means)
+ to engage in attacks on the DNS, thus threatening the global availability
+ and integrity of information on the Internet.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
- This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementors.<a href="#section-1-2" class="pilcrow">¶</a></p>
-<p id="section-1-3"><a href="#section-1-3" class="pilcrow">¶</a></p>
+ DNS was not designed with security as a goal. This makes it very
+ vulnerable, especially to attackers that have the technical capabilities
+ of an entire nationstate at their disposal.
+ This specification describes a censorship-resistant, privacy-preserving
+ and decentralized name system: The GNU Name System (GNS). It is designed
+ to provide a secure alternative to DNS, especially when censorship or
+ manipulation is encountered. GNS can bind names to any kind of
+ cryptographically secured token, enabling it to double in some respects as
+ even as an alternative to some of today's Public Key Infrastructures, in
+ particular X.509 for the Web.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-3">
+ This document contains the GNU Name System (GNS) technical specification
+ of the GNU Name System (GNS), a fully decentralized and censorship-resistant
+ name system. GNS provides a privacy-enhancing alternative to the Domain
+ Name System (DNS). The design of GNS incorporates the capability to
+ integrate and coexist with DNS. GNS is based on the principle of a petname
+ system and builds on ideas from the Simple Distributed Security
+ Infrastructure (SDSI), addressing a central issue with the decentralized
+ mapping of secure identifiers to memorable names: namely the impossibility
+ of providing a global, secure and memorable mapping without a trusted
+ authority. GNS uses the transitivity in the SDSI design to replace the
+ trusted root with secure delegation of authority thus making petnames
+ useful to other users while operating under a very strong adversary model.<a href="#section-1-3" class="pilcrow">¶</a></p>
+<p id="section-1-4">
+ This document defines the normative wire format of resource records, resolution processes,
+ cryptographic routines and security considerations for use by implementors.<a href="#section-1-4" class="pilcrow">¶</a></p>
+<p id="section-1-5"><a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="zones">
@@ -1156,43 +1185,43 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-zones" class="section-name selfRef">Zones</a>
</h2>
<p id="section-2-1">
- A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
- where d is the private key and zk the corresponding public key.
- GNS employs the curve parameters of the twisted edwards representation
- of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> (a.k.a. edwards25519)
- with the ECDSA scheme (<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>).
- The deterministic property of ECDSA (as opposed to EdDSA) is required
- in order to achieve zone privacy.
- In the following, we use the following naming convention for our
- cryptographic primitives:<a href="#section-2-1" class="pilcrow">¶</a></p>
+ A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
+ where d is the private key and zk the corresponding public key.
+ GNS employs the curve parameters of the twisted edwards representation
+ of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> (a.k.a. edwards25519)
+ with the ECDSA scheme (<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>).
+ The deterministic property of ECDSA (as opposed to EdDSA) is required
+ in order to achieve zone privacy.
+ In the following, we use the following naming convention for our
+ cryptographic primitives:<a href="#section-2-1" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-2-2">
<dt id="section-2-2.1">d</dt>
<dd id="section-2-2.2">
- is a 256-bit ECDSA private key.
- In GNS, records are signed using a key derived from "d" as described in
- <a href="#publish" class="xref">Section 4</a>.<a href="#section-2-2.2" class="pilcrow">¶</a>
+ is a 256-bit ECDSA private key.
+ In GNS, records are signed using a key derived from "d" as described in
+ <a href="#publish" class="xref">Section 4</a>.<a href="#section-2-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2-2.3">p</dt>
<dd id="section-2-2.4">
- is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, i.e.
- 2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
+ is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, i.e.
+ 2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2-2.5">B</dt>
<dd id="section-2-2.6">
- is the group generator (X(P),Y(P)) of edwards25519 as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.6" class="pilcrow">¶</a>
+ is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2-2.7">L</dt>
<dd id="section-2-2.8">
- is the order of edwards25519 in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8" class="pilcrow">¶</a>
+ is the order of edwards25519 in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2-2.9">zk</dt>
<dd id="section-2-2.10">
- is the ECDSA public key corresponding to d. It is defined in
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the curve point d*B where B is the group
- generator of the elliptic curve.
- The public key is used to uniquely identify a GNS zone and is referred to
- as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
+ is the ECDSA public key corresponding to d. It is defined in
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the curve point d*B where B is the group
+ generator of the elliptic curve.
+ The public key is used to uniquely identify a GNS zone and is referred to
+ as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1203,23 +1232,23 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-resource-records" class="section-name selfRef">Resource records</a>
</h2>
<p id="section-3-1">
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:<a href="#section-3-1" class="pilcrow">¶</a></p>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ </pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
</div>
@@ -1227,77 +1256,77 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-3-4">
<dt id="section-3-4.1">EXPIRATION</dt>
<dd id="section-3-4.2">
- denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
+ denotes the absolute 64-bit expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.3">DATA SIZE</dt>
<dd id="section-3-4.4">
- denotes the 32-bit size of the DATA field in bytes and in network byte
- order.<a href="#section-3-4.4" class="pilcrow">¶</a>
+ denotes the 32-bit size of the DATA field in bytes and in network byte
+ order.<a href="#section-3-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.5">TYPE</dt>
<dd id="section-3-4.6">
- is the 32-bit resource record type. This type can be one of the GNS resource
- records as defined in <a href="#rrecords" class="xref">Section 3</a> or a DNS record
- type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> or any of the
- complementary standardized DNS resource record types. This value must be
- stored in network byte order. Note that values
- below 2^16 are reserved for allocation via IANA (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-4.6" class="pilcrow">¶</a>
+ is the 32-bit resource record type. This type can be one of the GNS resource
+ records as defined in <a href="#rrecords" class="xref">Section 3</a> or a DNS record
+ type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> or any of the
+ complementary standardized DNS resource record types. This value must be
+ stored in network byte order. Note that values
+ below 2^16 are reserved for allocation via IANA (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.7">FLAGS</dt>
<dd id="section-3-4.8">
- is a 32-bit resource record flags field (see below).<a href="#section-3-4.8" class="pilcrow">¶</a>
+ is a 32-bit resource record flags field (see below).<a href="#section-3-4.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.9">DATA</dt>
<dd id="section-3-4.10">
- the variable-length resource record data payload. The contents are defined
- by the
- respective type of the resource record.<a href="#section-3-4.10" class="pilcrow">¶</a>
+ the variable-length resource record data payload. The contents are defined
+ by the
+ respective type of the resource record.<a href="#section-3-4.10" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3-5">
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:<a href="#section-3-5" class="pilcrow">¶</a></p>
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="figure_flag">
<figure id="figure-2">
<div class="artwork art-text alignLeft" id="section-3-6.1">
<pre>
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- </pre>
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ </pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a></figcaption></figure>
</div>
<p id="section-3-7">
- where:<a href="#section-3-7" class="pilcrow">¶</a></p>
+ where:<a href="#section-3-7" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-8">
<dt id="section-3-8.1">SHADOW</dt>
<dd id="section-3-8.2">
- If this flag is set, this record should be ignored by resolvers unless all (other)
- records of the same record type have expired. Used to allow zone publishers to
- facilitate good performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can propagate and may be
- cached before the transition becomes active.<a href="#section-3-8.2" class="pilcrow">¶</a>
+ If this flag is set, this record should be ignored by resolvers unless all (other)
+ records of the same record type have expired. Used to allow zone publishers to
+ facilitate good performance when records change by allowing them to put future
+ values of records into the DHT. This way, future values can propagate and may be
+ cached before the transition becomes active.<a href="#section-3-8.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-8.3">EXPREL</dt>
<dd id="section-3-8.4">
- The expiration time value of the record is a relative time (still in microseconds)
- and not an absolute time. This flag should never be encountered by a resolver
- for records obtained from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.<a href="#section-3-8.4" class="pilcrow">¶</a>
+ The expiration time value of the record is a relative time (still in microseconds)
+ and not an absolute time. This flag should never be encountered by a resolver
+ for records obtained from the DHT, but might be present when a resolver looks up
+ private records of a zone hosted locally.<a href="#section-3-8.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-8.5">PRIVATE</dt>
<dd id="section-3-8.6">
- This is a private record of this peer and it should thus not be
- published in the DHT. Thus, this flag should never be encountered by
- a resolver for records obtained from the DHT.
- Private records should still be considered just like
- regular records when resolving labels in local zones.<a href="#section-3-8.6" class="pilcrow">¶</a>
+ This is a private record of this peer and it should thus not be
+ published in the DHT. Thus, this flag should never be encountered by
+ a resolver for records obtained from the DHT.
+ Private records should still be considered just like
+ regular records when resolving labels in local zones.<a href="#section-3-8.6" class="pilcrow">¶</a>
</dd>
</dl>
<div id="gnsrecords_pkey">
@@ -1306,21 +1335,21 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-pkey" class="section-name selfRef">PKEY</a>
</h3>
<p id="section-3.1-1">In GNS, a delegation of a label to a zone is represented through a PKEY
- record. A PKEY resource record contains the public key of the zone to
- delegate to. A PKEY record MUST be the only record under a label. No other
- records are allowed. A PKEY DATA entry has the following format:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ record. A PKEY resource record contains the public key of the zone to
+ delegate to. A PKEY record MUST be the only record under a label. No other
+ records are allowed. A PKEY DATA entry has the following format:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.1-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
</div>
@@ -1332,40 +1361,40 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
</h3>
<p id="section-3.2-1">It is possible to delegate a label back into DNS through a GNS2DNS record.
- The resource record contains a DNS name for the resolver to continue with
- in DNS followed by a DNS server. Both names are in the format defined in
- <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
- If a resolver encounters a GNS2DNS record it is expected that it first
- resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
- numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
- The DNS server names may themselves be names in GNS or DNS. If the
- DNS server name ends in ".+", the rest of the name is to be interpreted
- relative to the zone of the GNS2DNS record.
- Then, the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the name server(s).
- Multiple
- GNS2DNS records may be stored under the same label, in which case the
- resolve MUST try all of them. However, if multiple GNS2DNS records
- are present, the DNS name MUST be identical for all of them.
- A GNS2DNS DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+ The resource record contains a DNS name for the resolver to continue with
+ in DNS followed by a DNS server. Both names are in the format defined in
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
+ If a resolver encounters a GNS2DNS record it is expected that it first
+ resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
+ numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
+ The DNS server names may themselves be names in GNS or DNS. If the
+ DNS server name ends in ".+", the rest of the name is to be interpreted
+ relative to the zone of the GNS2DNS record.
+ Then, the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved, and
+ resolved by querying the name server(s).
+ Multiple
+ GNS2DNS records may be stored under the same label, in which case the
+ resolve MUST try all of them. However, if multiple GNS2DNS records
+ are present, the DNS name MUST be identical for all of them.
+ A GNS2DNS DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-4">
<div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
+ </pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
</div>
@@ -1377,30 +1406,34 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-leho" class="section-name selfRef">LEHO</a>
</h3>
<p id="section-3.3-1">Legacy hostname records can be used by applications that are expected
- to supply a DNS name on the application layer. The most common use case
- is HTTP virtual hosting, which as-is would not work with GNS names as
- those may not be globally unique.
-
- A LEHO resource record contains an UTF-8 string (which is not 0-terminated)
- representing the legacy hostname to use.
- It is expected to be found together in a single
- resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+ to supply a DNS name on the application layer. The most common use case
+ is HTTP virtual hosting, which as-is would not work with GNS names as
+ those may not be globally unique.
+
+ A LEHO resource record contains an UTF-8 string (which is not 0-terminated)
+ representing the legacy hostname to use.
+ It is expected to be found together in a single
+ resource record with an IPv4 or IPv6 address.
+ A LEHO DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
</div>
+<p id="section-3.3-3">
+ NOTE: If an application uses a LEHO value in an HTTP reques header
+ (e.g. "Host:" header) it must be converted to a punycode representation
+ <span>[<a href="#RFC3492" class="xref">RFC3492</a>]</span>.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_box">
@@ -1409,56 +1442,56 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-box" class="section-name selfRef">BOX</a>
</h3>
<p id="section-3.4-1">
- In GNS, every "." in a name delegates to another zone, and
- GNS lookups are expected to return all of the required useful
- information in one record set. This is incompatible with the
- special labels used by DNS for SRV and TLSA records. Thus, GNS
- defines the BOX record format to box up SRV and TLSA records and
- include them in the record set of the label they are associated
- with. For example, a
- TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
- (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
- must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
- otherwise it is to be left untouched. This way, TLSA (and SRV)
- records do not require a separate network request, and TLSA
- records become inseparable from the corresponding address records.
- A BOX DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
+ In GNS, every "." in a name delegates to another zone, and
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with. For example, a
+ TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
+ "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
+ (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
+ otherwise it is to be left untouched. This way, TLSA (and SRV)
+ records do not require a separate network request, and TLSA
+ records become inseparable from the corresponding address records.
+ A BOX DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-6">
<div class="artwork art-text alignLeft" id="section-3.4-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PROTO | SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD DATA |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure>
</div>
<dl class="dlParallel" id="section-3.4-3">
<dt id="section-3.4-3.1">PROTO</dt>
<dd id="section-3.4-3.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.4-3.3">SVC</dt>
<dd id="section-3.4-3.4">
- the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.4-3.4" class="pilcrow">¶</a>
+ the 16-bit service value of the boxed record, i.e. the port number.
+ In network byte order.<a href="#section-3.4-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.4-3.5">TYPE</dt>
<dd id="section-3.4-3.6">
- is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
+ is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.4-3.7">RECORD DATA</dt>
<dd id="section-3.4-3.8">
- is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.4-3.8" class="pilcrow">¶</a>
+ is a variable length field containing the "DATA" format of TYPE as
+ defined for the respective TYPE in DNS.<a href="#section-3.4-3.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1471,12 +1504,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-publishing-records" class="section-name selfRef">Publishing records</a>
</h2>
<p id="section-4-1">
- GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the zone key "zk" and the respective label of the contained records.
- Given a label, the DHT key "q" is derived as follows:<a href="#section-4-1" class="pilcrow">¶</a></p>
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels, encrypted and
+ published together in a single block in the DHT.
+ A resource records block is published under a key "q" which is derived
+ from the zone key "zk" and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="blinding">
<section id="section-4.1">
<h3 id="name-key-derivations">
@@ -1484,57 +1517,57 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h3>
<div class="artwork art-text alignLeft" id="section-4.1-1">
<pre>
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h*d mod p
- zk_h := h*zk mod p
- q := SHA512 (zk_h)
- </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d_h := h*d mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
+ </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
</div>
<p id="section-4.1-2">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.1-3">
<dt id="section-4.1-3.1">PRK_h</dt>
<dd id="section-4.1-3.2">
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "zk" as initial
- keying material.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "zk" as initial
+ keying material.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.3">h</dt>
<dd id="section-4.1-3.4">
- is the 512-bit HKDF expansion result. The expansion info input is a
- concatenation of the label and string "gns".<a href="#section-4.1-3.4" class="pilcrow">¶</a>
+ is the 512-bit HKDF expansion result. The expansion info input is a
+ concatenation of the label and string "gns".<a href="#section-4.1-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.5">d</dt>
<dd id="section-4.1-3.6">
- is the 256-bit private zone key as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-3.6" class="pilcrow">¶</a>
+ is the 256-bit private zone key as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.7">label</dt>
<dd id="section-4.1-3.8">
- is a UTF-8 string under wich the resource records are published.<a href="#section-4.1-3.8" class="pilcrow">¶</a>
+ is a UTF-8 string under wich the resource records are published.<a href="#section-4.1-3.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.9">d_h</dt>
<dd id="section-4.1-3.10">
- is a 256-bit private key derived from the "d" using the
- keying material "h".<a href="#section-4.1-3.10" class="pilcrow">¶</a>
+ is a 256-bit private key derived from the "d" using the
+ keying material "h".<a href="#section-4.1-3.10" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.11">zk_h</dt>
<dd id="section-4.1-3.12">
- is a 256-bit public key derived from the zone key "zk" using the
- keying material "h".<a href="#section-4.1-3.12" class="pilcrow">¶</a>
+ is a 256-bit public key derived from the zone key "zk" using the
+ keying material "h".<a href="#section-4.1-3.12" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.13">p</dt>
<dd id="section-4.1-3.14">
- is the group order as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-3.14" class="pilcrow">¶</a>
+ is the group order as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-3.14" class="pilcrow">¶</a>
</dd>
<dt id="section-4.1-3.15">q</dt>
<dd id="section-4.1-3.16">
- Is the 512-bit DHT key under which the resource records block is
- published.
- It is the SHA512 hash over the public key "zk_h" corresponding to the
- derived private key "d_h".<a href="#section-4.1-3.16" class="pilcrow">¶</a>
+ Is the 512-bit DHT key under which the resource records block is
+ published.
+ It is the SHA512 hash over the public key "zk_h" corresponding to the
+ derived private key "d_h".<a href="#section-4.1-3.16" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1545,40 +1578,40 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-resource-records-block" class="section-name selfRef">Resource records block</a>
</h3>
<p id="section-4.2-1">
- GNS records are grouped by their labels and published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+ GNS records are grouped by their labels and published as a single
+ block in the DHT.
+ The contained resource records are encrypted using a symmetric
+ encryption scheme.
+ A GNS resource records block has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a></figcaption></figure>
</div>
@@ -1586,45 +1619,45 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-4.2-4">
<dt id="section-4.2-4.1">SIGNATURE</dt>
<dd id="section-4.2-4.2">
- A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The signature is computed over the data
- following the PUBLIC KEY field.
- The signature is created using the derived private key "d_h" (see
- <a href="#publish" class="xref">Section 4</a>).<a href="#section-4.2-4.2" class="pilcrow">¶</a>
+ A 512-bit ECDSA deterministic signature compliant with
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "d_h" (see
+ <a href="#publish" class="xref">Section 4</a>).<a href="#section-4.2-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
- is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
- wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
+ is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
+ wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
+ Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
- A 32-bit value containing the length of the signed data following the
- PUBLIC KEY field in network byte order. This value always includes the
- length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
- addition to the length of the BDATA.<a href="#section-4.2-4.6" class="pilcrow">¶</a>
+ A 32-bit value containing the length of the signed data following the
+ PUBLIC KEY field in network byte order. This value always includes the
+ length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
+ addition to the length of the BDATA.<a href="#section-4.2-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.7">PURPOSE</dt>
<dd id="section-4.2-4.8">
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
- is the 64-bit resource records block expiration time. This is the
- expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- If a records block includes shadow records, then the *maximum*
- expiration time of all shadow records with matching type and the
- expiration times of the non-shadow records is considered.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.<a href="#section-4.2-4.10" class="pilcrow">¶</a>
+ is the 64-bit resource records block expiration time. This is the
+ expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ If a records block includes shadow records, then the *maximum*
+ expiration time of all shadow records with matching type and the
+ expiration times of the non-shadow records is considered.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.<a href="#section-4.2-4.10" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.11">BDATA</dt>
<dd id="section-4.2-4.12">
- The encrypted resource records with a total size of SIZE - 16.<a href="#section-4.2-4.12" class="pilcrow">¶</a>
+ The encrypted resource records with a total size of SIZE - 16.<a href="#section-4.2-4.12" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1634,112 +1667,112 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-block-data-encryption-and-d" class="section-name selfRef">Block data encryption and decryption</a>
</h3>
<p id="section-4.3-1">
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the zone key "zk".
- Upon receiving a resource records block, first the validity of a given
- "zk_h" MUST be checked by computing "h" from "zk" and label and
- verifying that both are equal. This step is mandatory to prevent record
- spoofing.
- For decryption of the resource records block payload,
- the key material "K" and initialization vector "IV" for the
- symmetric en-/decryption are derived:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the zone key "zk".
+ Upon receiving a resource records block, first the validity of a given
+ "zk_h" MUST be checked by computing "h" from "zk" and label and
+ verifying that both are equal. This step is mandatory to prevent record
+ spoofing.
+ For decryption of the resource records block payload,
+ the key material "K" and initialization vector "IV" for the
+ symmetric en-/decryption are derived:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
- PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
- PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
- K := HKDF-Expand (PRK_k, label, 512 / 8);
- IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, label, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, label, 256 / 8)
+ </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">
- HKDF is a hash-based key derivation function as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
- extraction phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vectors.
- We divide the resulting keying material "K" into a 256-bit AES
- <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
- and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+ HKDF is a hash-based key derivation function as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
+ extraction phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vectors.
+ We divide the resulting keying material "K" into a 256-bit AES
+ <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
+ and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
</div>
<p id="section-4.3-5">
- Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+ Similarly, we divide "IV" into a 128-bit initialization vector
+ and a 128-bit initialization vector:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-6.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
</div>
<p id="section-4.3-7">
- The keys and IVs are used for a CFB128-AES-256 and
- CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
- Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
+ The keys and IVs are used for a CFB128-AES-256 and
+ CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-8">
<pre>
- RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
- BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
+ </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
</div>
<p id="section-4.3-9">
- The decrypted RDATA has the following format:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
+ The decrypted RDATA has the following format:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
<div id="figure_rdata">
<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
+ </pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
</div>
@@ -1747,19 +1780,19 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-4.3-12">
<dt id="section-4.3-12.1">RR COUNT</dt>
<dd id="section-4.3-12.2">
- A 32-bit value containing the number of variable-length resource
- records which are
- following after this field in network byte order.
- The resource record format is defined in <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-4.3-12.2" class="pilcrow">¶</a>
+ A 32-bit value containing the number of variable-length resource
+ records which are
+ following after this field in network byte order.
+ The resource record format is defined in <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-4.3-12.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.3-12.3">PADDING</dt>
<dd id="section-4.3-12.4">
- The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA is a power of two.
+ The padding MUST contain the value 0 in all octets.
+ The padding MUST ensure that the size of the RDATA is a power of two.
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST NOT contain
- other records.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST NOT contain
+ other records.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1771,10 +1804,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-internationalization-and-ch" class="section-name selfRef">Internationalization and Character Encoding</a>
</h2>
<p id="section-5-1">
- All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>.
- This does not include any DNS names found in DNS records, such as CNAME
- records, which are internationalized through the IDNA specifications
- <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
+ All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>.
+ This does not include any DNS names found in DNS records, such as CNAME
+ records, which are internationalized through the IDNA specifications
+ <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -1783,7 +1816,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-6-1">
- TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1792,7 +1825,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-record-resolution" class="section-name selfRef">Record Resolution</a>
</h2>
<p id="section-7-1">
- TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="revocation">
@@ -1801,7 +1834,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-namespace-revocation" class="section-name selfRef">Namespace Revocation</a>
</h2>
<p id="section-8-1">
- TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
@@ -1810,7 +1843,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-9-1">
- This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
+ This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
@@ -1818,134 +1851,134 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
</h2>
<p id="section-10-1">
- The following represents a test vector for a record of type MX with
- a priority of 10 and the mail hostname mail.example.com.<a href="#section-10-1" class="pilcrow">¶</a></p>
+ The following represents a test vector for a record of type MX with
+ a priority of 10 and the mail hostname mail.example.com.<a href="#section-10-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-10-2">
<pre>
- label := "mail"
-
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
-
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
-
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
-
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
- 81b0e7e4405c10bd
- 0017c802f7d32e18
-
- zk_h (derived zone key) :=
- 8cb514a56c0eaae0
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291
-
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
-
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
-
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
-
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
-
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
-
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
- 00000000
-
-
- BDATA :=
- d99d08fa123da096
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
-
- SIGNATURE :=
- 055cb070e05fe6de r
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54___________
- 07e731a34680ee33 s
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46
-
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
- </pre><a href="#section-10-2" class="pilcrow">¶</a>
+ label := "mail"
+
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
+
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
+
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
+
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
+
+ zk_h (derived zone key) :=
+ 8cb514a56c0eaae0
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291
+
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
+
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
+
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
+
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
+
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
+
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
+ 0000000000000000
+ 00000000
+
+
+ BDATA :=
+ d99d08fa123da096
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+
+ SIGNATURE :=
+ 055cb070e05fe6de r
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54___________
+ 07e731a34680ee33 s
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46
+
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+ </pre><a href="#section-10-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-11">
@@ -1959,6 +1992,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC1035">[RFC1035]</dt>
<dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11">November 1987</time>, <span><<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>></span>. </dd>
+<dt id="RFC3492">[RFC3492]</dt>
+ <dd>
+<span class="refAuthor">Costello, A.</span>, <span class="refTitle">"Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)"</span>, <span class="seriesInfo">RFC 3492</span>, <span class="seriesInfo">DOI 10.17487/RFC3492</span>, <time datetime="2003-03">March 2003</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3492">https://www.rfc-editor.org/info/rfc3492</a>></span>. </dd>
<dt id="RFC3629">[RFC3629]</dt>
<dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11">November 2003</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>></span>. </dd>
@@ -1968,7 +2004,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC5869">[RFC5869]</dt>
<dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>. </dd>
<dt id="RFC5890">[RFC5890]</dt>
<dd>
@@ -1979,7 +2015,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC6979">[RFC6979]</dt>
<dd>
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
"</span>, <span class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>. </dd>
<dt id="RFC7748">[RFC7748]</dt>
<dd>
@@ -1990,7 +2026,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
- The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
+ The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
"</span>, <time datetime="1999-03">March 1999</time>. </dd>
</dl>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -61,30 +61,68 @@ Internet-Draft The GNU Name System July 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resource records . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 7
- 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 7
- 4.2. Resource records block . . . . . . . . . . . . . . . . . 8
- 4.3. Block data encryption and decryption . . . . . . . . . . 9
- 5. Internationalization and Character Encoding . . . . . . . . . 11
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 12
- 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 12
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
+ 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Resource records block . . . . . . . . . . . . . . . . . 9
+ 4.3. Block data encryption and decryption . . . . . . . . . . 10
+ 5. Internationalization and Character Encoding . . . . . . . . . 12
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
+ 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 13
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 16
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
+ The Domain Name System (DNS) is a unique distributed database and a
+ vital service for most Internet applications. While DNS is
+ distributed, it relies on centralized, trusted registrars to provide
+ globally unique names. As the awareness of the central role DNS
+ plays on the Internet rises, various institutions are using their
+ power (including legal means) to engage in attacks on the DNS, thus
+ threatening the global availability and integrity of information on
+ the Internet.
+
+ DNS was not designed with security as a goal. This makes it very
+ vulnerable, especially to attackers that have the technical
+ capabilities of an entire nationstate at their disposal. This
+ specification describes a censorship-resistant, privacy-preserving
+ and decentralized name system: The GNU Name System (GNS). It is
+ designed to provide a secure alternative to DNS, especially when
+ censorship or manipulation is encountered. GNS can bind names to any
+ kind of cryptographically secured token, enabling it to double in
+ some respects as even as an alternative to some of today's Public Key
+ Infrastructures, in particular X.509 for the Web.
+
This document contains the GNU Name System (GNS) technical
- specification for secure, censorship-resistant and decentralised name
- resolution.
+ specification of the GNU Name System (GNS), a fully decentralized and
+ censorship-resistant name system. GNS provides a privacy-enhancing
+ alternative to the Domain Name System (DNS). The design of GNS
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 2]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ incorporates the capability to integrate and coexist with DNS. GNS
+ is based on the principle of a petname system and builds on ideas
+ from the Simple Distributed Security Infrastructure (SDSI),
+ addressing a central issue with the decentralized mapping of secure
+ identifiers to memorable names: namely the impossibility of providing
+ a global, secure and memorable mapping without a trusted authority.
+ GNS uses the transitivity in the SDSI design to replace the trusted
+ root with secure delegation of authority thus making petnames useful
+ to other users while operating under a very strong adversary model.
This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security
@@ -105,15 +143,6 @@ Table of Contents
d is a 256-bit ECDSA private key. In GNS, records are signed using
a key derived from "d" as described in Section 4.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 2]
-
-Internet-Draft The GNU Name System July 2019
-
-
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- 19.
@@ -132,16 +161,25 @@ Internet-Draft The GNU Name System July 2019
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined as follows:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 3]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
Figure 1
@@ -163,13 +201,6 @@ Internet-Draft The GNU Name System July 2019
FLAGS is a 32-bit resource record flags field (see below).
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 3]
-
-Internet-Draft The GNU Name System July 2019
-
-
DATA the variable-length resource record data payload. The contents
are defined by the respective type of the resource record.
@@ -178,15 +209,23 @@ Internet-Draft The GNU Name System July 2019
illustrates the flag distribution in the 32-bit flag value of a
resource record:
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
Figure 2
where:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 4]
+
+Internet-Draft The GNU Name System July 2019
+
+
SHADOW If this flag is set, this record should be ignored by
resolvers unless all (other) records of the same record type have
expired. Used to allow zone publishers to facilitate good
@@ -214,25 +253,13 @@ Internet-Draft The GNU Name System July 2019
label. No other records are allowed. A PKEY DATA entry has the
following format:
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 4]
-
-Internet-Draft The GNU Name System July 2019
-
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3
@@ -247,6 +274,14 @@ Internet-Draft The GNU Name System July 2019
addresses, allowing the resolver to skip this step. The DNS server
names may themselves be names in GNS or DNS. If the DNS server name
ends in ".+", the rest of the name is to be interpreted relative to
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
+
the zone of the GNS2DNS record. Then, the DNS name from the GNS2DNS
record is appended to the remainder of the name to be resolved, and
resolved by querying the name server(s). Multiple GNS2DNS records
@@ -255,33 +290,21 @@ Internet-Draft The GNU Name System July 2019
the DNS name MUST be identical for all of them. A GNS2DNS DATA entry
has the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
Figure 4
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
3.3. LEHO
Legacy hostname records can be used by applications that are expected
@@ -293,16 +316,28 @@ Internet-Draft The GNU Name System July 2019
single resource record with an IPv4 or IPv6 address. A LEHO DATA
entry has the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 5
+ NOTE: If an application uses a LEHO value in an HTTP reques header
+ (e.g. "Host:" header) it must be converted to a punycode
+ representation [RFC3492].
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
3.4. BOX
In GNS, every "." in a name delegates to another zone, and GNS
@@ -321,22 +356,15 @@ Internet-Draft The GNU Name System July 2019
the corresponding address records. A BOX DATA entry has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PROTO | SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD DATA |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6
@@ -352,22 +380,36 @@ Internet-Draft The GNU Name System July 2019
RECORD DATA is a variable length field containing the "DATA" format
of TYPE as defined for the respective TYPE in DNS.
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
4. Publishing records
GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT. A resource records block is
- published under a key which is derived from the zone key "zk" and the
- respective label of the contained records. Given a label, the DHT
- key "q" is derived as follows:
+ Resource records are grouped by their respective labels, encrypted
+ and published together in a single block in the DHT. A resource
+ records block is published under a key "q" which is derived from the
+ zone key "zk" and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:
4.1. Key derivations
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h*d mod p
- zk_h := h*zk mod p
- q := SHA512 (zk_h)
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d_h := h*d mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
@@ -385,15 +427,6 @@ Internet-Draft The GNU Name System July 2019
label is a UTF-8 string under wich the resource records are
published.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
d_h is a 256-bit private key derived from the "d" using the keying
material "h".
@@ -406,6 +439,17 @@ Internet-Draft The GNU Name System July 2019
published. It is the SHA512 hash over the public key "zk_h"
corresponding to the derived private key "d_h".
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
4.2. Resource records block
GNS records are grouped by their labels and published as a single
@@ -413,43 +457,35 @@ Internet-Draft The GNU Name System July 2019
a symmetric encryption scheme. A GNS resource records block has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 7
where:
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
SIGNATURE A 512-bit ECDSA deterministic signature compliant with
[RFC6979]. The signature is computed over the data following the
PUBLIC KEY field. The signature is created using the derived
@@ -461,6 +497,15 @@ Internet-Draft The GNU Name System July 2019
SIZE A 32-bit value containing the length of the signed data
following the PUBLIC KEY field in network byte order. This value
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
always includes the length of the fields SIZE (4), PURPOSE (4) and
EXPIRATION (8) in addition to the length of the BDATA.
@@ -490,53 +535,59 @@ Internet-Draft The GNU Name System July 2019
initialization vector "IV" for the symmetric en-/decryption are
derived:
- PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
- PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
- K := HKDF-Expand (PRK_k, label, 512 / 8);
- IV := HKDF-Expand (PRK_iv, label, 256 / 8)
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, label, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, label, 256 / 8)
HKDF is a hash-based key derivation function as defined in [RFC5869].
Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-
SHA256 for the expansion phase. The output keying material is 64
+ octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
+ the initialization vectors. We divide the resulting keying material
+ "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
+ key:
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
- octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
- the initialization vectors. We divide the resulting keying material
- "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
- key:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 8
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 9
@@ -544,8 +595,8 @@ Internet-Draft The GNU Name System July 2019
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
(CFB) mode [RFC3826].
- RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
- BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
The decrypted RDATA has the following format:
@@ -557,34 +608,39 @@ Internet-Draft The GNU Name System July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
Internet-Draft The GNU Name System July 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
Figure 10
@@ -613,7 +669,7 @@ Internet-Draft The GNU Name System July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
Internet-Draft The GNU Name System July 2019
@@ -639,149 +695,149 @@ Internet-Draft The GNU Name System July 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
- label := "mail"
+ label := "mail"
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
Internet-Draft The GNU Name System July 2019
- 81b0e7e4405c10bd
- 0017c802f7d32e18
-
- zk_h (derived zone key) :=
- 8cb514a56c0eaae0
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291
-
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
-
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
-
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
-
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
-
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
-
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
+
+ zk_h (derived zone key) :=
+ 8cb514a56c0eaae0
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291
+
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
+
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
+
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
+
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
+
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
+
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
+ 0000000000000000
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
Internet-Draft The GNU Name System July 2019
- 00000000
-
-
- BDATA :=
- d99d08fa123da096
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
-
- SIGNATURE :=
- 055cb070e05fe6de r
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54___________
- 07e731a34680ee33 s
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46
-
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
+ 00000000
+
+
+ BDATA :=
+ d99d08fa123da096
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+
+ SIGNATURE :=
+ 055cb070e05fe6de r
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54___________
+ 07e731a34680ee33 s
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46
+
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
Internet-Draft The GNU Name System July 2019
@@ -796,6 +852,11 @@ Internet-Draft The GNU Name System July 2019
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications
+ (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
+ <https://www.rfc-editor.org/info/rfc3492>.
+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
@@ -829,19 +890,19 @@ Internet-Draft The GNU Name System July 2019
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
- [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
- Signature Algorithm (EdDSA)", RFC 8032,
- DOI 10.17487/RFC8032, January 2017,
- <https://www.rfc-editor.org/info/rfc8032>.
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
Internet-Draft The GNU Name System July 2019
+ [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+ Signature Algorithm (EdDSA)", RFC 8032,
+ DOI 10.17487/RFC8032, January 2017,
+ <https://www.rfc-editor.org/info/rfc8032>.
+
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
@@ -888,9 +949,4 @@ Authors' Addresses
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -64,863 +64,900 @@
</abstract>
</front>
<middle>
- <section anchor="introduction" numbered="true" toc="default">
- <name>Introduction</name>
- <t>
- This document contains the GNU Name System (GNS) technical specification
- for secure, censorship-resistant and decentralised name resolution.
- </t>
- <t>
- This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementors.
- </t>
- <t>
+ <section anchor="introduction" numbered="true" toc="default">
+ <name>Introduction</name>
+ <t>
+ The Domain Name System (DNS) is a unique distributed database and a vital
+ service for most Internet applications. While DNS is distributed, it
+ relies on centralized, trusted registrars to provide globally unique
+ names. As the awareness of the central role DNS plays on the Internet
+ rises, various institutions are using their power (including legal means)
+ to engage in attacks on the DNS, thus threatening the global availability
+ and integrity of information on the Internet.
+ </t>
+ <t>
+ DNS was not designed with security as a goal. This makes it very
+ vulnerable, especially to attackers that have the technical capabilities
+ of an entire nationstate at their disposal.
+ This specification describes a censorship-resistant, privacy-preserving
+ and decentralized name system: The GNU Name System (GNS). It is designed
+ to provide a secure alternative to DNS, especially when censorship or
+ manipulation is encountered. GNS can bind names to any kind of
+ cryptographically secured token, enabling it to double in some respects as
+ even as an alternative to some of today’s Public Key Infrastructures, in
+ particular X.509 for the Web.
+ </t>
+ <t>
+ This document contains the GNU Name System (GNS) technical specification
+ of the GNU Name System (GNS), a fully decentralized and censorship-resistant
+ name system. GNS provides a privacy-enhancing alternative to the Domain
+ Name System (DNS). The design of GNS incorporates the capability to
+ integrate and coexist with DNS. GNS is based on the principle of a petname
+ system and builds on ideas from the Simple Distributed Security
+ Infrastructure (SDSI), addressing a central issue with the decentralized
+ mapping of secure identifiers to memorable names: namely the impossibility
+ of providing a global, secure and memorable mapping without a trusted
+ authority. GNS uses the transitivity in the SDSI design to replace the
+ trusted root with secure delegation of authority thus making petnames
+ useful to other users while operating under a very strong adversary model.
+ </t>
+ <t>
+ This document defines the normative wire format of resource records, resolution processes,
+ cryptographic routines and security considerations for use by implementors.
+ </t>
+ <t>
- </t>
- </section>
- <section anchor="zones" numbered="true" toc="default">
- <name>Zones</name>
- <t>
- A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
- where d is the private key and zk the corresponding public key.
- GNS employs the curve parameters of the twisted edwards representation
- of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
- with the ECDSA scheme (<xref target="RFC6979" />).
- The deterministic property of ECDSA (as opposed to EdDSA) is required
- in order to achieve zone privacy.
- In the following, we use the following naming convention for our
- cryptographic primitives:
- </t>
- <dl>
- <dt>d</dt>
- <dd>
- is a 256-bit ECDSA private key.
- In GNS, records are signed using a key derived from "d" as described in
- <xref target="publish" />.
- </dd>
- <dt>p</dt>
- <dd>
- is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
- 2^255 - 19.
- </dd>
- <dt>B</dt>
- <dd>
- is the group generator (X(P),Y(P)) of edwards25519 as defined in
- <xref target="RFC7748" />.
- </dd>
- <dt>L</dt>
- <dd>
- is the order of edwards25519 in <xref target="RFC7748" />.
- </dd>
- <dt>zk</dt>
- <dd>
- is the ECDSA public key corresponding to d. It is defined in
- <xref target="RFC6979" /> as the curve point d*B where B is the group
- generator of the elliptic curve.
- The public key is used to uniquely identify a GNS zone and is referred to
- as the "zone key".
- </dd>
- </dl>
+ </t>
+ </section>
+ <section anchor="zones" numbered="true" toc="default">
+ <name>Zones</name>
+ <t>
+ A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
+ where d is the private key and zk the corresponding public key.
+ GNS employs the curve parameters of the twisted edwards representation
+ of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
+ with the ECDSA scheme (<xref target="RFC6979" />).
+ The deterministic property of ECDSA (as opposed to EdDSA) is required
+ in order to achieve zone privacy.
+ In the following, we use the following naming convention for our
+ cryptographic primitives:
+ </t>
+ <dl>
+ <dt>d</dt>
+ <dd>
+ is a 256-bit ECDSA private key.
+ In GNS, records are signed using a key derived from "d" as described in
+ <xref target="publish" />.
+ </dd>
+ <dt>p</dt>
+ <dd>
+ is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
+ 2^255 - 19.
+ </dd>
+ <dt>B</dt>
+ <dd>
+ is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ <xref target="RFC7748" />.
+ </dd>
+ <dt>L</dt>
+ <dd>
+ is the order of edwards25519 in <xref target="RFC7748" />.
+ </dd>
+ <dt>zk</dt>
+ <dd>
+ is the ECDSA public key corresponding to d. It is defined in
+ <xref target="RFC6979" /> as the curve point d*B where B is the group
+ generator of the elliptic curve.
+ The public key is used to uniquely identify a GNS zone and is referred to
+ as the "zone key".
+ </dd>
+ </dl>
- </section>
- <section anchor="rrecords" numbered="true" toc="default">
- <name>Resource records</name>
- <t>
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:
- </t>
- <figure anchor="figure_gnsrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>EXPIRATION</dt>
- <dd>
- denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.
- </dd>
- <dt>DATA SIZE</dt>
- <dd>
- denotes the 32-bit size of the DATA field in bytes and in network byte
- order.
- </dd>
- <dt>TYPE</dt>
- <dd>
- is the 32-bit resource record type. This type can be one of the GNS resource
- records as defined in <xref target="rrecords" /> or a DNS record
- type as defined in <xref target="RFC1035" /> or any of the
- complementary standardized DNS resource record types. This value must be
- stored in network byte order. Note that values
- below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />).
- </dd>
- <dt>FLAGS</dt>
- <dd>
- is a 32-bit resource record flags field (see below).
- </dd>
- <dt>DATA</dt>
- <dd>
- the variable-length resource record data payload. The contents are defined
- by the
- respective type of the resource record.
- </dd>
- </dl>
- <t>
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:</t>
- <figure anchor="figure_flag">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- where:
- </t>
- <dl>
- <dt>SHADOW</dt>
- <dd>
- If this flag is set, this record should be ignored by resolvers unless all (other)
- records of the same record type have expired. Used to allow zone publishers to
- facilitate good performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can propagate and may be
- cached before the transition becomes active.
- </dd>
- <dt>EXPREL</dt>
- <dd>
- The expiration time value of the record is a relative time (still in microseconds)
- and not an absolute time. This flag should never be encountered by a resolver
- for records obtained from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.
- </dd>
- <dt>PRIVATE</dt>
- <dd>
- This is a private record of this peer and it should thus not be
- published in the DHT. Thus, this flag should never be encountered by
- a resolver for records obtained from the DHT.
- Private records should still be considered just like
- regular records when resolving labels in local zones.
- </dd>
- </dl>
-<section anchor="gnsrecords_pkey" numbered="true" toc="default">
- <name>PKEY</name>
- <t>In GNS, a delegation of a label to a zone is represented through a PKEY
- record. A PKEY resource record contains the public key of the zone to
- delegate to. A PKEY record MUST be the only record under a label. No other
- records are allowed. A PKEY DATA entry has the following format:</t>
- <figure anchor="figure_pkeyrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
-</section>
-<section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
- <name>GNS2DNS</name>
- <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
- The resource record contains a DNS name for the resolver to continue with
- in DNS followed by a DNS server. Both names are in the format defined in
- <xref target="RFC1034" /> for DNS names.
- If a resolver encounters a GNS2DNS record it is expected that it first
- resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
- numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
- The DNS server names may themselves be names in GNS or DNS. If the
- DNS server name ends in ".+", the rest of the name is to be interpreted
- relative to the zone of the GNS2DNS record.
- Then, the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the name server(s).
- Multiple
- GNS2DNS records may be stored under the same label, in which case the
- resolve MUST try all of them. However, if multiple GNS2DNS records
- are present, the DNS name MUST be identical for all of them.
- A GNS2DNS DATA entry has the following format:</t>
- <figure anchor="figure_gns2dnsrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
-</section>
+ </section>
+ <section anchor="rrecords" numbered="true" toc="default">
+ <name>Resource records</name>
+ <t>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:
+ </t>
+ <figure anchor="figure_gnsrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>EXPIRATION</dt>
+ <dd>
+ denotes the absolute 64-bit expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.
+ </dd>
+ <dt>DATA SIZE</dt>
+ <dd>
+ denotes the 32-bit size of the DATA field in bytes and in network byte
+ order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ is the 32-bit resource record type. This type can be one of the GNS resource
+ records as defined in <xref target="rrecords" /> or a DNS record
+ type as defined in <xref target="RFC1035" /> or any of the
+ complementary standardized DNS resource record types. This value must be
+ stored in network byte order. Note that values
+ below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />).
+ </dd>
+ <dt>FLAGS</dt>
+ <dd>
+ is a 32-bit resource record flags field (see below).
+ </dd>
+ <dt>DATA</dt>
+ <dd>
+ the variable-length resource record data payload. The contents are defined
+ by the
+ respective type of the resource record.
+ </dd>
+ </dl>
+ <t>
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:</t>
+ <figure anchor="figure_flag">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>SHADOW</dt>
+ <dd>
+ If this flag is set, this record should be ignored by resolvers unless all (other)
+ records of the same record type have expired. Used to allow zone publishers to
+ facilitate good performance when records change by allowing them to put future
+ values of records into the DHT. This way, future values can propagate and may be
+ cached before the transition becomes active.
+ </dd>
+ <dt>EXPREL</dt>
+ <dd>
+ The expiration time value of the record is a relative time (still in microseconds)
+ and not an absolute time. This flag should never be encountered by a resolver
+ for records obtained from the DHT, but might be present when a resolver looks up
+ private records of a zone hosted locally.
+ </dd>
+ <dt>PRIVATE</dt>
+ <dd>
+ This is a private record of this peer and it should thus not be
+ published in the DHT. Thus, this flag should never be encountered by
+ a resolver for records obtained from the DHT.
+ Private records should still be considered just like
+ regular records when resolving labels in local zones.
+ </dd>
+ </dl>
+ <section anchor="gnsrecords_pkey" numbered="true" toc="default">
+ <name>PKEY</name>
+ <t>In GNS, a delegation of a label to a zone is represented through a PKEY
+ record. A PKEY resource record contains the public key of the zone to
+ delegate to. A PKEY record MUST be the only record under a label. No other
+ records are allowed. A PKEY DATA entry has the following format:</t>
+ <figure anchor="figure_pkeyrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
+ <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
+ <name>GNS2DNS</name>
+ <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
+ The resource record contains a DNS name for the resolver to continue with
+ in DNS followed by a DNS server. Both names are in the format defined in
+ <xref target="RFC1034" /> for DNS names.
+ If a resolver encounters a GNS2DNS record it is expected that it first
+ resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
+ numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
+ The DNS server names may themselves be names in GNS or DNS. If the
+ DNS server name ends in ".+", the rest of the name is to be interpreted
+ relative to the zone of the GNS2DNS record.
+ Then, the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved, and
+ resolved by querying the name server(s).
+ Multiple
+ GNS2DNS records may be stored under the same label, in which case the
+ resolve MUST try all of them. However, if multiple GNS2DNS records
+ are present, the DNS name MUST be identical for all of them.
+ A GNS2DNS DATA entry has the following format:</t>
+ <figure anchor="figure_gns2dnsrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
-<section anchor="gnsrecords_leho" numbered="true" toc="default">
- <name>LEHO</name>
- <t>Legacy hostname records can be used by applications that are expected
- to supply a DNS name on the application layer. The most common use case
- is HTTP virtual hosting, which as-is would not work with GNS names as
- those may not be globally unique.
+ <section anchor="gnsrecords_leho" numbered="true" toc="default">
+ <name>LEHO</name>
+ <t>Legacy hostname records can be used by applications that are expected
+ to supply a DNS name on the application layer. The most common use case
+ is HTTP virtual hosting, which as-is would not work with GNS names as
+ those may not be globally unique.
- A LEHO resource record contains an UTF-8 string (which is not 0-terminated)
- representing the legacy hostname to use.
- It is expected to be found together in a single
- resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry has the following format:</t>
- <figure anchor="figure_lehorecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
-</section>
-<section anchor="gnsrecords_box" numbered="true" toc="default">
- <name>BOX</name>
- <t>
- In GNS, every "." in a name delegates to another zone, and
- GNS lookups are expected to return all of the required useful
- information in one record set. This is incompatible with the
- special labels used by DNS for SRV and TLSA records. Thus, GNS
- defines the BOX record format to box up SRV and TLSA records and
- include them in the record set of the label they are associated
- with. For example, a
- TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
- (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
- must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
- otherwise it is to be left untouched. This way, TLSA (and SRV)
- records do not require a separate network request, and TLSA
- records become inseparable from the corresponding address records.
- A BOX DATA entry has the following format:</t>
- <figure anchor="figure_boxrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <dl>
- <dt>PROTO</dt>
- <dd>
- the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
- </dd>
- <dt>SVC</dt>
- <dd>
- the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.
- </dd>
- <dt>TYPE</dt>
- <dd>
- is the 32-bit record type of the boxed record. In network byte order.
- </dd>
- <dt>RECORD DATA</dt>
- <dd>
- is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.
- </dd>
- </dl>
-</section>
+ A LEHO resource record contains an UTF-8 string (which is not 0-terminated)
+ representing the legacy hostname to use.
+ It is expected to be found together in a single
+ resource record with an IPv4 or IPv6 address.
+ A LEHO DATA entry has the following format:</t>
+ <figure anchor="figure_lehorecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ NOTE: If an application uses a LEHO value in an HTTP reques header
+ (e.g. "Host:" header) it must be converted to a punycode representation
+ <xref target="RFC3492" />.
+ </t>
+ </section>
+ <section anchor="gnsrecords_box" numbered="true" toc="default">
+ <name>BOX</name>
+ <t>
+ In GNS, every "." in a name delegates to another zone, and
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with. For example, a
+ TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
+ "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
+ (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
+ otherwise it is to be left untouched. This way, TLSA (and SRV)
+ records do not require a separate network request, and TLSA
+ records become inseparable from the corresponding address records.
+ A BOX DATA entry has the following format:</t>
+ <figure anchor="figure_boxrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PROTO | SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD DATA |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <dl>
+ <dt>PROTO</dt>
+ <dd>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
+ </dd>
+ <dt>SVC</dt>
+ <dd>
+ the 16-bit service value of the boxed record, i.e. the port number.
+ In network byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ is the 32-bit record type of the boxed record. In network byte order.
+ </dd>
+ <dt>RECORD DATA</dt>
+ <dd>
+ is a variable length field containing the "DATA" format of TYPE as
+ defined for the respective TYPE in DNS.
+ </dd>
+ </dl>
+ </section>
- </section>
+ </section>
- <section anchor="publish" numbered="true" toc="default">
- <name>Publishing records</name>
- <t>
- GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the zone key "zk" and the respective label of the contained records.
- Given a label, the DHT key "q" is derived as follows:
- </t>
- <section anchor="blinding" numbered="true" toc="default">
- <name>Key derivations</name>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h*d mod p
- zk_h := h*zk mod p
- q := SHA512 (zk_h)
- ]]></artwork>
- <t>
- We use a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- </t>
- <dl>
- <dt>PRK_h</dt>
- <dd>
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "zk" as initial
- keying material.
- </dd>
- <dt>h</dt>
- <dd>
- is the 512-bit HKDF expansion result. The expansion info input is a
- concatenation of the label and string "gns".
- </dd>
- <dt>d</dt>
- <dd>
- is the 256-bit private zone key as defined in <xref target="zones" />.
- </dd>
- <dt>label</dt>
- <dd>
- is a UTF-8 string under wich the resource records are published.
- </dd>
- <dt>d_h</dt>
- <dd>
- is a 256-bit private key derived from the "d" using the
- keying material "h".
- </dd>
- <dt>zk_h</dt>
- <dd>
- is a 256-bit public key derived from the zone key "zk" using the
- keying material "h".
- </dd>
- <dt>p</dt>
- <dd>
- is the group order as defined in <xref target="zones" />.
- </dd>
- <dt>q</dt>
- <dd>
- Is the 512-bit DHT key under which the resource records block is
- published.
- It is the SHA512 hash over the public key "zk_h" corresponding to the
- derived private key "d_h".
- </dd>
- </dl>
- </section>
- <section anchor="wire" numbered="true" toc="default">
- <name>Resource records block</name>
- <t>
- GNS records are grouped by their labels and published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:
- </t>
- <figure anchor="figure_record_block">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- </figure>
- <t>where:</t>
- <dl>
- <dt>SIGNATURE</dt>
- <dd>
- A 512-bit ECDSA deterministic signature compliant with
- <xref target="RFC6979" />. The signature is computed over the data
- following the PUBLIC KEY field.
- The signature is created using the derived private key "d_h" (see
- <xref target="publish" />).
- </dd>
- <dt>PUBLIC KEY</dt>
- <dd>
- is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
- wire format of this value is defined in <xref target="RFC8032" />,
- Section 5.1.5.
- </dd>
- <dt>SIZE</dt>
- <dd>
- A 32-bit value containing the length of the signed data following the
- PUBLIC KEY field in network byte order. This value always includes the
- length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
- addition to the length of the BDATA.
- </dd>
- <dt>PURPOSE</dt>
- <dd>
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).
- </dd>
- <dt>EXPIRATION</dt>
- <dd>
- is the 64-bit resource records block expiration time. This is the
- expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- If a records block includes shadow records, then the *maximum*
- expiration time of all shadow records with matching type and the
- expiration times of the non-shadow records is considered.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.
- </dd>
- <dt>BDATA</dt>
- <dd>
- The encrypted resource records with a total size of SIZE - 16.
- </dd>
- </dl>
- </section>
- <section numbered="true" toc="default">
- <name>Block data encryption and decryption</name>
- <t>
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the zone key "zk".
- Upon receiving a resource records block, first the validity of a given
- "zk_h" MUST be checked by computing "h" from "zk" and label and
- verifying that both are equal. This step is mandatory to prevent record
- spoofing.
- For decryption of the resource records block payload,
- the key material "K" and initialization vector "IV" for the
- symmetric en-/decryption are derived:
- </t>
- <!-- OLD VERSION
- PRK_kiv := HKDF-Extract (zk, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- -->
- <artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
- PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
- K := HKDF-Expand (PRK_k, label, 512 / 8);
- IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- ]]></artwork>
- <t>
- HKDF is a hash-based key derivation function as defined in
- <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
- extraction phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vectors.
- We divide the resulting keying material "K" into a 256-bit AES
- <xref target="RFC3826" /> key
- and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
- </t>
- <figure anchor="figure_hkdf_keys">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:
- </t>
- <figure anchor="figure_hkdf_ivs">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
+ <section anchor="publish" numbered="true" toc="default">
+ <name>Publishing records</name>
+ <t>
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels, encrypted and
+ published together in a single block in the DHT.
+ A resource records block is published under a key "q" which is derived
+ from the zone key "zk" and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:
+ </t>
+ <section anchor="blinding" numbered="true" toc="default">
+ <name>Key derivations</name>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d_h := h*d mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
+ ]]></artwork>
+ <t>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ </t>
+ <dl>
+ <dt>PRK_h</dt>
+ <dd>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "zk" as initial
+ keying material.
+ </dd>
+ <dt>h</dt>
+ <dd>
+ is the 512-bit HKDF expansion result. The expansion info input is a
+ concatenation of the label and string "gns".
+ </dd>
+ <dt>d</dt>
+ <dd>
+ is the 256-bit private zone key as defined in <xref target="zones" />.
+ </dd>
+ <dt>label</dt>
+ <dd>
+ is a UTF-8 string under wich the resource records are published.
+ </dd>
+ <dt>d_h</dt>
+ <dd>
+ is a 256-bit private key derived from the "d" using the
+ keying material "h".
+ </dd>
+ <dt>zk_h</dt>
+ <dd>
+ is a 256-bit public key derived from the zone key "zk" using the
+ keying material "h".
+ </dd>
+ <dt>p</dt>
+ <dd>
+ is the group order as defined in <xref target="zones" />.
+ </dd>
+ <dt>q</dt>
+ <dd>
+ Is the 512-bit DHT key under which the resource records block is
+ published.
+ It is the SHA512 hash over the public key "zk_h" corresponding to the
+ derived private key "d_h".
+ </dd>
+ </dl>
+ </section>
+ <section anchor="wire" numbered="true" toc="default">
+ <name>Resource records block</name>
+ <t>
+ GNS records are grouped by their labels and published as a single
+ block in the DHT.
+ The contained resource records are encrypted using a symmetric
+ encryption scheme.
+ A GNS resource records block has the following format:
+ </t>
+ <figure anchor="figure_record_block">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>SIGNATURE</dt>
+ <dd>
+ A 512-bit ECDSA deterministic signature compliant with
+ <xref target="RFC6979" />. The signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "d_h" (see
+ <xref target="publish" />).
+ </dd>
+ <dt>PUBLIC KEY</dt>
+ <dd>
+ is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
+ wire format of this value is defined in <xref target="RFC8032" />,
+ Section 5.1.5.
+ </dd>
+ <dt>SIZE</dt>
+ <dd>
+ A 32-bit value containing the length of the signed data following the
+ PUBLIC KEY field in network byte order. This value always includes the
+ length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
+ addition to the length of the BDATA.
+ </dd>
+ <dt>PURPOSE</dt>
+ <dd>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).
+ </dd>
+ <dt>EXPIRATION</dt>
+ <dd>
+ is the 64-bit resource records block expiration time. This is the
+ expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ If a records block includes shadow records, then the *maximum*
+ expiration time of all shadow records with matching type and the
+ expiration times of the non-shadow records is considered.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.
+ </dd>
+ <dt>BDATA</dt>
+ <dd>
+ The encrypted resource records with a total size of SIZE - 16.
+ </dd>
+ </dl>
+ </section>
+ <section numbered="true" toc="default">
+ <name>Block data encryption and decryption</name>
+ <t>
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the zone key "zk".
+ Upon receiving a resource records block, first the validity of a given
+ "zk_h" MUST be checked by computing "h" from "zk" and label and
+ verifying that both are equal. This step is mandatory to prevent record
+ spoofing.
+ For decryption of the resource records block payload,
+ the key material "K" and initialization vector "IV" for the
+ symmetric en-/decryption are derived:
+ </t>
+ <!-- OLD VERSION
+ PRK_kiv := HKDF-Extract (zk, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ -->
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, label, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, label, 256 / 8)
+ ]]></artwork>
+ <t>
+ HKDF is a hash-based key derivation function as defined in
+ <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
+ extraction phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vectors.
+ We divide the resulting keying material "K" into a 256-bit AES
+ <xref target="RFC3826" /> key
+ and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
+ </t>
+ <figure anchor="figure_hkdf_keys">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ Similarly, we divide "IV" into a 128-bit initialization vector
+ and a 128-bit initialization vector:
+ </t>
+ <figure anchor="figure_hkdf_ivs">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
- <t>
- The keys and IVs are used for a CFB128-AES-256 and
- CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
- Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
- BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- ]]></artwork>
- <t>
- The decrypted RDATA has the following format:
- </t>
- <figure anchor="figure_rdata">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>RR COUNT</dt>
- <dd>
- A 32-bit value containing the number of variable-length resource
- records which are
- following after this field in network byte order.
- The resource record format is defined in <xref target="rrecords" />.
- </dd>
- <dt>PADDING</dt>
- <dd>
- The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA is a power of two.
+ <t>
+ The keys and IVs are used for a CFB128-AES-256 and
+ CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
+ Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
+ ]]></artwork>
+ <t>
+ The decrypted RDATA has the following format:
+ </t>
+ <figure anchor="figure_rdata">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>RR COUNT</dt>
+ <dd>
+ A 32-bit value containing the number of variable-length resource
+ records which are
+ following after this field in network byte order.
+ The resource record format is defined in <xref target="rrecords" />.
+ </dd>
+ <dt>PADDING</dt>
+ <dd>
+ The padding MUST contain the value 0 in all octets.
+ The padding MUST ensure that the size of the RDATA is a power of two.
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST NOT contain
- other records.
- </dd>
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST NOT contain
+ other records.
+ </dd>
- </dl>
- </section>
- </section>
- <section anchor="encoding" numbered="true" toc="default">
- <name>Internationalization and Character Encoding</name>
- <t>
- All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
- This does not include any DNS names found in DNS records, such as CNAME
- records, which are internationalized through the IDNA specifications
- <xref target="RFC5890" />.
- </t>
- </section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="resolution" numbered="true" toc="default">
- <name>Record Resolution</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="revocation" numbered="true" toc="default">
- <name>Namespace Revocation</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="iana" numbered="true" toc="default">
- <name>IANA Considerations</name>
- <t>
- This will be fun
- </t>
- </section>
- <!-- iana -->
- <section>
- <name>Test Vectors</name>
- <t>
- The following represents a test vector for a record of type MX with
- a priority of 10 and the mail hostname mail.example.com.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- label := "mail"
+ </dl>
+ </section>
+ </section>
+ <section anchor="encoding" numbered="true" toc="default">
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
+ This does not include any DNS names found in DNS records, such as CNAME
+ records, which are internationalized through the IDNA specifications
+ <xref target="RFC5890" />.
+ </t>
+ </section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="resolution" numbered="true" toc="default">
+ <name>Record Resolution</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="revocation" numbered="true" toc="default">
+ <name>Namespace Revocation</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="iana" numbered="true" toc="default">
+ <name>IANA Considerations</name>
+ <t>
+ This will be fun
+ </t>
+ </section>
+ <!-- iana -->
+ <section>
+ <name>Test Vectors</name>
+ <t>
+ The following represents a test vector for a record of type MX with
+ a priority of 10 and the mail hostname mail.example.com.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ label := "mail"
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
- 81b0e7e4405c10bd
- 0017c802f7d32e18
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
- zk_h (derived zone key) :=
- 8cb514a56c0eaae0
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291
+ zk_h (derived zone key) :=
+ 8cb514a56c0eaae0
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
- 00000000
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
+ 0000000000000000
+ 00000000
- BDATA :=
- d99d08fa123da096
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
+ BDATA :=
+ d99d08fa123da096
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
- SIGNATURE :=
- 055cb070e05fe6de r
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54___________
- 07e731a34680ee33 s
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46
+ SIGNATURE :=
+ 055cb070e05fe6de r
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54___________
+ 07e731a34680ee33 s
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
- ]]></artwork>
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+ ]]></artwork>
- </section>
-</middle>
-<back>
- <references>
- <name>Normative References</name>
- <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
- <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
- <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
- <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
- <front>
- <title>
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- </title>
- <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
- <organization/>
- </author>
- <author initials="P." surname="Eronen" fullname="P. Eronen">
- <organization/>
- </author>
- <date year="2010" month="May"/>
- <abstract>
- <t>
- This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="5869"/>
- <seriesInfo name="DOI" value="10.17487/RFC5869"/>
- </reference>
- <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
- </reference>
- <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
- <front>
- <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
- <author initials="S." surname="Josefsson" fullname="S. Josefsson">
- <organization/>
- </author>
- <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
- <organization/>
- </author>
- <date year="2017" month="January"/>
- <abstract>
- <t>
- This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="8032"/>
- <seriesInfo name="DOI" value="10.17487/RFC8032"/>
- </reference>
- <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
- <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
- <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
- <front>
- <title>Domain names - implementation and specification</title>
- <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
- <organization/>
- </author>
- <date year="1987" month="November"/>
- <abstract>
- <t>
- This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
- </t>
- </abstract>
- </front>
- <seriesInfo name="STD" value="13"/>
- <seriesInfo name="RFC" value="1035"/>
- <seriesInfo name="DOI" value="10.17487/RFC1035"/>
- </reference>
- <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
- <front>
- <title>
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- </title>
- <author initials="T." surname="Pornin" fullname="T. Pornin">
- <organization/>
- </author>
- <date year="2013" month="August"/>
- <abstract>
- <t>
- This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="6979"/>
- <seriesInfo name="DOI" value="10.17487/RFC6979"/>
- </reference>
- <reference anchor="TWOFISH">
- <front>
- <title>
- The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
- </title>
- <author initials="B." surname="Schneier" fullname="B. Schneier">
- <organization/>
- </author>
- <date year="1999" month="March"/>
- </front>
- </reference>
+ </section>
+ </middle>
+ <back>
+ <references>
+ <name>Normative References</name>
+ <reference anchor="RFC3492" target="https://www.rfc-editor.org/info/rfc3492"><front><title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title><author initials="A." surname="Costello" fullname="A. Costello"><organization/></author><date year="2003" month="March"/><abstract><t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3492"/><seriesInfo name="DOI" value="10.17487/RFC3492"/></reference>
+ <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
+ <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
+ <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
+ <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
+ <front>
+ <title>
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ </title>
+ <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
+ <organization/>
+ </author>
+ <author initials="P." surname="Eronen" fullname="P. Eronen">
+ <organization/>
+ </author>
+ <date year="2010" month="May"/>
+ <abstract>
+ <t>
+ This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
+ </reference>
+ <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
+ </reference>
+ <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
+ <front>
+ <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
+ <author initials="S." surname="Josefsson" fullname="S. Josefsson">
+ <organization/>
+ </author>
+ <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
+ <organization/>
+ </author>
+ <date year="2017" month="January"/>
+ <abstract>
+ <t>
+ This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8032"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8032"/>
+ </reference>
+ <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
+ <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
+ <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
+ <front>
+ <title>Domain names - implementation and specification</title>
+ <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
+ <organization/>
+ </author>
+ <date year="1987" month="November"/>
+ <abstract>
+ <t>
+ This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1035"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1035"/>
+ </reference>
+ <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
+ <front>
+ <title>
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
+ </title>
+ <author initials="T." surname="Pornin" fullname="T. Pornin">
+ <organization/>
+ </author>
+ <date year="2013" month="August"/>
+ <abstract>
+ <t>
+ This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6979"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6979"/>
+ </reference>
+ <reference anchor="TWOFISH">
+ <front>
+ <title>
+ The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
+ </title>
+ <author initials="B." surname="Schneier" fullname="B. Schneier">
+ <organization/>
+ </author>
+ <date year="1999" month="March"/>
+ </front>
+ </reference>
- <!-- <reference anchor="ISO20022">
- <front>
- <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
- <author>
- <organization>International Organization for Standardization</organization>
- <address>
- <uri>http://www.iso.ch</uri>
- </address>
- </author>
- <date month="May" year="2013"/>
- </front>
- </reference>-->
- </references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
-</back>
+ <!-- <reference anchor="ISO20022">
+ <front>
+ <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
+ <author>
+ <organization>International Organization for Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ </reference>-->
+ </references>
+ <!-- Change Log
+ v00 2017-07-23 MS Initial version
+ -->
+ </back>
</rfc>
