[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: add note for punycode for
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: add note for punycode for host headers |
|
Date: |
Fri, 04 Oct 2019 20:21:38 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new a665828 add note for punycode for host headers
a665828 is described below
commit a665828bc7566f5d5aed5155eb47a66a235b205f
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Fri Oct 4 20:19:28 2019 +0200
add note for punycode for host headers
---
draft-schanzen-gns.html | 990 ++++++++++++++-------------
draft-schanzen-gns.txt | 766 +++++++++++----------
draft-schanzen-gns.xml | 1701 ++++++++++++++++++++++++-----------------------
3 files changed, 1793 insertions(+), 1664 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 4e23f72..7cb2452 100644
--- 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
index b65f73e..ec982fc 100644
--- 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
index 87bdb8a..d4e65e1 100644
--- 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 [...]
- <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" [...]
- <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), [...]
- <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 comp [...]
- </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, erro
[...]
- <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
forwardin [...]
- <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 [...]
- </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 [...]
+ <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 field [...]
+ <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 [...]
+ <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) [...]
+ <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 com [...]
+ </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, err
[...]
+ <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
forwardi [...]
+ <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 [...]
+ </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>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: add note for punycode for host headers,
gnunet <=