commit 9f9d3512175008cdda66e309dd4b68426ea510fa
parent 3a76cba5563fe4d459aed27deb63e696580fcec4
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 18:58:02 +0200
update documents
Diffstat:
2 files changed, 96 insertions(+), 90 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1158,7 +1158,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-2-1">
A zone in GNS is defined by a public/private ECC key pair (d,zk),
where d is the private key and zk the corresponding public key.
- GNS combines the EC parameters of Ed25519 (<span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>)
+ GNS employs the curve parameters of the twisted edwards representation
+ of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> (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.
@@ -1167,29 +1168,31 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-2-2">
<dt id="section-2-2.1">d</dt>
<dd id="section-2-2.2">
- is a private key. It is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span> as a b-bit
- string. In our case, b is 256.
+ 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 Ed25519 as defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>, i.e.
+ 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 of the elliptic curve as defined in
- <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span> for Ed25519.<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">zk</dt>
+ <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>
+</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. Note that this is NOT a Ed25519 public
- key.
+ 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.8" class="pilcrow">¶</a>
+ as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1978,6 +1981,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
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>
+<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, M.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>></span>. </dd>
<dt id="RFC8032">[RFC8032]</dt>
<dd>
<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01">January 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>></span>. </dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -65,7 +65,7 @@ Table of Contents
3. Resource records . . . . . . . . . . . . . . . . . . . . . . 3
3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 7
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 7
@@ -95,17 +95,17 @@ Table of Contents
A zone in GNS is defined by a public/private ECC key pair (d,zk),
where d is the private key and zk the corresponding public key. GNS
- combines the EC parameters of Ed25519 ([RFC8032]) with the ECDSA
- scheme ([RFC6979]). The deterministic property of ECDSA (as opposed
- to EdDSA) is required in order to achieve zone privacy. In the
+ employs the curve parameters of the twisted edwards representation of
+ Curve25519 [RFC7748] (edwards25519) with the ECDSA scheme
+ ([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:
- d is a private key. It is defined in [RFC8032] as a b-bit string.
- In our case, b is 256. In GNS, records are signed using a key
- derived from "d" as described in Section 4.
+ d is a 256-bit ECDSA private key. In GNS, records are signed using
+ a key derived from "d" as described in Section 4.
+
- p is the prime of Ed25519 as defined in [RFC8032], i.e. 2^255 - 19.
@@ -114,14 +114,18 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
- B is the group generator of the elliptic curve as defined in
- [RFC8032] for Ed25519.
+ p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
+ - 19.
+
+ B is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ [RFC7748].
+
+ L is the order of edwards25519 in [RFC7748].
zk is the ECDSA public key corresponding to d. It is defined in
[RFC6979] as the curve point d*B where B is the group generator of
- the elliptic curve. Note that this is NOT a Ed25519 public key.
- The public key is used to uniquely identify a GNS zone and is
- referred to as the "zone key".
+ the elliptic curve. The public key is used to uniquely identify a
+ GNS zone and is referred to as the "zone key".
3. Resource records
@@ -159,10 +163,6 @@ Internet-Draft The GNU Name System July 2019
FLAGS is a 32-bit resource record flags field (see below).
- DATA the variable-length resource record data payload. The contents
- are defined by the respective type of the resource record.
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 3]
@@ -170,6 +170,9 @@ 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.
+
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
@@ -211,13 +214,10 @@ Internet-Draft The GNU Name System July 2019
label. No other records are allowed. A PKEY DATA entry has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+
+
@@ -226,6 +226,14 @@ 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 |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
Figure 3
3.2. GNS2DNS
@@ -262,16 +270,8 @@ Internet-Draft The GNU Name System July 2019
Figure 4
-3.3. LEHO
- 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 a string (which is not 0-terminated) representing the legacy
- hostname to use (FIXME: in UTF-8 or PUNY?). 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:
+
@@ -282,6 +282,17 @@ 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
+ 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 a string (which is not 0-terminated) representing the legacy
+ hostname to use (FIXME: in UTF-8 or PUNY?). 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:
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
@@ -320,6 +331,13 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
Figure 6
PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
@@ -331,13 +349,6 @@ Internet-Draft The GNU Name System July 2019
TYPE is the 32-bit record type of the boxed record. In network byte
order.
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-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.
@@ -374,6 +385,15 @@ 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".
@@ -386,14 +406,6 @@ 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 7]
-
-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
@@ -430,6 +442,14 @@ Internet-Draft The GNU Name System July 2019
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
@@ -441,15 +461,6 @@ 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 8]
-
-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.
@@ -487,17 +498,6 @@ Internet-Draft The GNU Name System July 2019
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:
-
-
-
-
-
-
-
@@ -506,6 +506,11 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 9]
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 |
@@ -552,11 +557,6 @@ Internet-Draft The GNU Name System July 2019
-
-
-
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
@@ -825,15 +825,15 @@ Internet-Draft The GNU Name System July 2019
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
+ [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+ 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>.
- [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
- 128-Bit Block Cipher, 1st Edition", March 1999.
-
-
@@ -842,6 +842,9 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 15]
Internet-Draft The GNU Name System July 2019
+ [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
+ 128-Bit Block Cipher, 1st Edition", March 1999.
+
Authors' Addresses
Martin Schanzenbach
@@ -890,7 +893,4 @@ Authors' Addresses
-
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 16]
