commit 89f16969de55adb5cb095bdfa25b71a4ac0c7c59
parent e7df043d73f099756a27e16836e362662efd31fb
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 8 Nov 2019 14:23:15 -0500
also add compiled files
Diffstat:
2 files changed, 166 insertions(+), 221 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1500,20 +1500,6 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-box" class="section-name selfRef">BOX</a>
</h3>
<p id="section-3.5-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.5-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-7">
@@ -2100,7 +2086,20 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a href="#name-box-2" class="section-name selfRef">BOX</a>
</h4>
<p id="section-6.3.4-1">
- TODO<a href="#section-6.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 href="#section-6.3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="vpn_processing">
@@ -2110,9 +2109,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h4>
<p id="section-6.3.5-1">
If the queried record type is either A or AAAA and the retrieved
- record set contains a VPN record, the resolver must open a VPN
- tunnel (cite someplace? This is difficult to define!) and return
- the IPv4 or IPv6 tunnel address, respectively.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
+ record set contains at least one VPN record, the resolver must open a
+ tunnel and return the IPv4 or IPv6 tunnel address, respectively.
+ The type of tunnel depends on the contents of the VPN record data.
+ No result is returned if the resolver implementation does not
+ support any of the tunnnels provided in the VPN records.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -69,21 +69,21 @@ Table of Contents
3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 9
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 9
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 10
+ 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 9
4.3. Record Data Encryption and Decryption . . . . . . . . . . 11
- 5. Internationalization and Character Encoding . . . . . . . . . 14
- 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 15
+ 5. Internationalization and Character Encoding . . . . . . . . . 13
+ 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 14
6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 15
- 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 15
6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 17
@@ -364,35 +364,7 @@ Internet-Draft The GNU Name System July 2019
3.5. BOX
- 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:
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
+ A BOX DATA entry has the following format:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -415,6 +387,13 @@ 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 7]
+
+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.
@@ -437,19 +416,6 @@ Internet-Draft The GNU Name System July 2019
Figure 8
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
4. Publishing Records
GNS resource records are published in a distributed hash table (DHT).
@@ -475,6 +441,15 @@ Internet-Draft The GNU Name System July 2019
SHA256 for the expansion phase.
PRK_h is key material retrieved using an HKDF using the string "key-
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
derivation" as salt and the public zone key "zk" as initial keying
material.
@@ -498,14 +473,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 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
We point out that the multiplication of "zk" with "h" is a point
multiplication, while the multiplication of "d" with "h" is a scalar
multiplication.
@@ -519,6 +486,26 @@ Internet-Draft The GNU Name System July 2019
underlying DHT. This may include a periodic refresh publication. A
GNS RRBLOCK has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
@@ -553,15 +540,6 @@ Internet-Draft The GNU Name System July 2019
PUBLIC KEY field. The signature is created using the derived
private key "d_h" (see Section 4).
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
-
-
PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify
SIGNATURE. The wire format of this value is defined in [RFC8032],
Section 5.1.5.
@@ -577,6 +555,13 @@ Internet-Draft The GNU Name System July 2019
PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
network byte order).
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+Internet-Draft The GNU Name System July 2019
+
+
EXPIRATION Specifies when the RRBLOCK expires and the encrypted
block SHOULD be removed from the DHT and caches as it is likely
stale. However, applications MAY continue to use non-expired
@@ -597,27 +582,6 @@ Internet-Draft The GNU Name System July 2019
set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
the RDATA looks as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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- /
@@ -646,6 +610,14 @@ Internet-Draft The GNU Name System July 2019
where:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
RR COUNT A 32-bit value containing the number of variable-length
resource records which are following after this field in network
byte order.
@@ -665,15 +637,6 @@ Internet-Draft The GNU Name System July 2019
records block payload, the key material "K" and initialization vector
"IV" for the symmetric cipher are derived as follows:
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
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);
@@ -702,6 +665,15 @@ Internet-Draft The GNU Name System July 2019
Figure 11
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -723,13 +695,6 @@ Internet-Draft The GNU Name System July 2019
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
5. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
@@ -756,6 +721,15 @@ Internet-Draft The GNU Name System July 2019
If the TLD is a Base32-encoded public zone key "zk", the entry zone
of the resolution process is implicitly given by the name.
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
@@ -778,14 +752,6 @@ Internet-Draft The GNU Name System July 2019
SHOULD be configurable through the GNS implementation. A mapping has
the form "prefix = public zone key". The prefix may consist of
multiple GNS labels concatenated with a ".". If multiple prefixes
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
match the name to resolve, the longest prefix is chosen. The prefix
length of two results cannot be equal, as this would indicate a
misconfiguration.
@@ -812,6 +778,14 @@ Internet-Draft The GNU Name System July 2019
1. Extract the right-most label from the name to look up.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
2. Calculate q using the label and zk.
3. Perform a DHT query GET(q) to retrieve the RRBLOCK.
@@ -834,14 +808,6 @@ Internet-Draft The GNU Name System July 2019
If the remainder of the name to resolve is empty but we have received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
label "@" as remaining name. If the record type to be resolved is
PKEY, the PKEY record set is returned and the resolution is
concluded.
@@ -868,6 +834,14 @@ Internet-Draft The GNU Name System July 2019
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 resolver MUST try all of
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
them. However, if multiple GNS2DNS records are present, the DNS name
MUST be identical for all of them.
@@ -888,26 +862,41 @@ Internet-Draft The GNU Name System July 2019
6.3.4. BOX
- TODO
+ 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.
+6.3.5. VPN
+ If the queried record type is either A or AAAA and the retrieved
+ record set contains at least one VPN record, the resolver must open a
+ tunnel and return the IPv4 or IPv6 tunnel address, respectively. The
+ type of tunnel depends on the contents of the VPN record data. No
+ result is returned if the resolver implementation does not support
+ any of the tunnnels provided in the VPN records.
+7. Zone Revocation
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
+ TODO
-6.3.5. VPN
- If the queried record type is either A or AAAA and the retrieved
- record set contains a VPN record, the resolver must open a VPN tunnel
- (cite someplace? This is difficult to define!) and return the IPv4
- or IPv6 tunnel address, respectively.
-7. Zone Revocation
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
- TODO
8. Security Considerations
@@ -946,14 +935,6 @@ Internet-Draft The GNU Name System July 2019
6668e9f684f4dc33
6d656b27392b0fee
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
d_h :=
01fb61f482c17633
77611c4c2509e0f3
@@ -965,6 +946,14 @@ Internet-Draft The GNU Name System July 2019
f4e29a3310767e3b
8b38bc1b276ce2ba
9bf1b49df1e120a3
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+
+Internet-Draft The GNU Name System July 2019
+
+
20ecc9dffb68416f
11729ad878ad3bdf
d0b4db2626b620d7
@@ -1002,14 +991,6 @@ Internet-Draft The GNU Name System July 2019
00000000
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
@@ -1021,6 +1002,14 @@ Internet-Draft The GNU Name System July 2019
10df4f39f5ba9f46____________
8cb514a56c0eaae0 zk_h
56745158a63ee4dd
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
+
+Internet-Draft The GNU Name System July 2019
+
+
76853cb9545e326e
76d7fa920f818291____________
000000540000000f SIZE (=84) | PURPOSE (=15)
@@ -1057,15 +1046,6 @@ Internet-Draft The GNU Name System July 2019
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
-
-Internet-Draft The GNU Name System July 2019
-
-
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
@@ -1079,6 +1059,13 @@ Internet-Draft The GNU Name System July 2019
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 19]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
@@ -1114,14 +1101,6 @@ Authors' Addresses
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 20]
-
-Internet-Draft The GNU Name System July 2019
-
-
CH-2501 Biel/Bienne
Switzerland
@@ -1138,39 +1117,4 @@ Internet-Draft The GNU Name System July 2019
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 21]
+Schanzenbach, et al. Expires 24 January 2020 [Page 20]
