commit 1e4f9902a4c03d8b5f40d189f590c5ad0155ffd9
parent c182a1b9aa53b9b9d1b98854556ce6abc2707022
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Mon, 10 Feb 2020 21:30:12 +0100
more revocation
Diffstat:
3 files changed, 215 insertions(+), 171 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -2082,32 +2082,32 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
is the result and the recursion is concluded.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
<li id="section-6.2-2.2">
- Case 2:
- If the name to be resolved is of the format
- "_SERVICE._PROTO" and the record set contains one or more matching BOX
- records, the records in the BOX records are the result and the recusion
- is concluded (<a href="#box_processing" class="xref">Section 6.2.4</a>).<a href="#section-6.2-2.2" class="pilcrow">¶</a>
+ Case 2:
+ If the name to be resolved is of the format
+ "_SERVICE._PROTO" and the record set contains one or more matching BOX
+ records, the records in the BOX records are the result and the recusion
+ is concluded (<a href="#box_processing" class="xref">Section 6.2.4</a>).<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
<li id="section-6.2-2.3">
Case 3:
If the remainder of the name to resolve is not empty and
- does not match the "_SERVICE._PROTO" syntax, then the current record set
+ does not match the "_SERVICE._PROTO" syntax, then the current record set
MUST consist of a single PKEY record
- (<a href="#pkey_processing" class="xref">Section 6.2.1</a>),
- a single CNAME record
- (<a href="#cname_processing" class="xref">Section 6.2.3</a>),
+ (<a href="#pkey_processing" class="xref">Section 6.2.1</a>),
+ a single CNAME record
+ (<a href="#cname_processing" class="xref">Section 6.2.3</a>),
or one or more GNS2DNS records
- (<a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
- which are processed
- as described in the respective sections below.
- Otherwise, resolution fails
+ (<a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
+ which are processed
+ as described in the respective sections below.
+ Otherwise, resolution fails
and the resolver MUST return an empty record set.
- Finally, after the recursion terminates, the client preferences
- for the record type SHOULD be considered. If a VPN record is found
- and the client requests an A or AAAA record, the VPN record
- SHOULD be converted (<a href="#vpn_processing" class="xref">Section 6.2.5</a>)
- if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
+ Finally, after the recursion terminates, the client preferences
+ for the record type SHOULD be considered. If a VPN record is found
+ and the client requests an A or AAAA record, the VPN record
+ SHOULD be converted (<a href="#vpn_processing" class="xref">Section 6.2.5</a>)
+ if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
</li>
</ol>
<div id="pkey_processing">
@@ -2170,15 +2170,15 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
record (<a href="#gnsrecords_leho" class="xref">Section 3.4</a>) with a relative
expiration time of one hour.<a href="#section-6.2.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2.2-5">
- GNS resolvers SHOULD offer a configuration
- option to disable DNS processing to avoid information leakage
- and provide a consistent security profile for all name resolutions.
- Such resolvers would return an empty record set upon encountering
- a GNS2DNS record during the recursion. However, if GNS2DNS records
- are encountered in the record set for the apex and a GNS2DNS record
- is expicitly requested by the application, such records MUST
- still be returned, even if DNS support is disabled by the
- GNS resolver configuration.<a href="#section-6.2.2-5" class="pilcrow">¶</a></p>
+ GNS resolvers SHOULD offer a configuration
+ option to disable DNS processing to avoid information leakage
+ and provide a consistent security profile for all name resolutions.
+ Such resolvers would return an empty record set upon encountering
+ a GNS2DNS record during the recursion. However, if GNS2DNS records
+ are encountered in the record set for the apex and a GNS2DNS record
+ is expicitly requested by the application, such records MUST
+ still be returned, even if DNS support is disabled by the
+ GNS resolver configuration.<a href="#section-6.2.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cname_processing">
@@ -2226,7 +2226,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.2.5" class="section-number selfRef">6.2.5. </a><a href="#name-vpn-2" class="section-name selfRef">VPN</a>
</h4>
<p id="section-6.2.5-1">
- At the end of the recursion,
+ At the end of the recursion,
if the queried record type is either A or AAAA and the retrieved
record set contains at least one VPN record, the resolver SHOULD
open a tunnel and return the IPv4 or IPv6 tunnel address,
@@ -2283,16 +2283,28 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<figure id="figure-15">
<div class="artwork art-text alignLeft" id="section-7-6.1">
<pre>
- skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
- skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", skey)
- enc := AES (skey, skey_iv, REVDAT)
- REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+ DK := scrypt (P := REV)
+ IV := IVderive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", DK)
+ EREV := AES (DK, IV, REV) /* TODO this is more complex */
+ REVDATA := scrypt(P := enc)
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
<p id="section-7-7">
+ where "scrypt" is the scrypt algorithm as defined in
+ <span>[<a href="#RFC7914" class="xref">RFC7914</a>]</span> with the following parameters set:<a href="#section-7-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-7-8">
+<pre>
+ S := "gnunet-revocation-proof-of-work" /* Salt */
+ N := 1 /* CPU memory cost parameter TODO spec says >1!!! */
+ r := 8 /* Block size */
+ p := 2 /* Parallelization parameter */
+ dkLen := 512 /* Intended output length */
+ </pre><a href="#section-7-8" class="pilcrow">¶</a>
+</div>
+<p id="section-7-9">
The above function is called with different values for the "NONCE" in
- "REVDAT" until the amount of leading zeroes is greater or equal 25.<a href="#section-7-7" class="pilcrow">¶</a></p>
+ "REVDAT" until the amount of leading zeroes is greater or equal 25.<a href="#section-7-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="governance">
@@ -2307,7 +2319,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
which points to a local or remote start zone key.
A resolver client may also determine the start zone from the
suffix of the name given for resolution or using information
- retrieved out of band.
+ retrieved out of band.
The governance model of any zone is at the sole discretion
of the zone owner. However, the choice of start zone(s) is at the sole
discretion of the local system administrator or user.<a href="#section-8-1" class="pilcrow">¶</a></p>
@@ -2316,13 +2328,13 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
where root zone governance is centralized at the Internet Corporation
for Assigned Names and Numbers (ICANN).
In DNS terminology, GNS roughly follows the idea of a hyper-hyper
- local root zone deployment, with the difference that it is not
- expected that all deployments use the same local root zone.<a href="#section-8-2" class="pilcrow">¶</a></p>
+ local root zone deployment, with the difference that it is not
+ expected that all deployments use the same local root zone.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">
In the following, we give examples how a local client resolver SHOULD
discover the start zone. The process given is not exhaustive and
clients MAY suppliement it with other mechanisms or ignore it if the
- particular application requires a different process.<a href="#section-8-3" class="pilcrow">¶</a></p>
+ particular application requires a different process.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">
GNS clients SHOULD first try to interpret the top-level domain of
a GNS name as a zone key.
@@ -2339,11 +2351,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-8-6">
In GNS, users MAY own and manage their own zones.
Each local zone SHOULD be associated with a single GNS label,
- but users MAY choose to use longer names consisting of
- multiple labels.
+ but users MAY choose to use longer names consisting of
+ multiple labels.
If the name of a locally managed zone matches the suffix
- of the name to be resolved,
- resolution SHOULD start from the respective local zone:<a href="#section-8-6" class="pilcrow">¶</a></p>
+ of the name to be resolved,
+ resolution SHOULD start from the respective local zone:<a href="#section-8-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-7">
<pre>
Example name: www.example.gnu
@@ -2364,8 +2376,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
".". If multiple suffixes match the name to resolve, the longest
matching suffix MUST BE used. The suffix length of two results
cannot be equal, as this would indicate a misconfiguration.
- If both a locally managed zone and a configuration entry exist
- for the same suffix, the locally managed zone MUST have priority.<a href="#section-8-8" class="pilcrow">¶</a></p>
+ If both a locally managed zone and a configuration entry exist
+ for the same suffix, the locally managed zone MUST have priority.<a href="#section-8-8" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-9">
<pre>
Example name: www.example.gnu
@@ -2547,6 +2559,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<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="RFC7914">[RFC7914]</dt>
+ <dd>
+<span class="refAuthor">Percival, C.</span><span class="refAuthor"> and S. Josefsson</span>, <span class="refTitle">"The scrypt Password-Based Key Derivation Function"</span>, <span class="seriesInfo">RFC 7914</span>, <span class="seriesInfo">DOI 10.17487/RFC7914</span>, <time datetime="2016-08">August 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7914">https://www.rfc-editor.org/info/rfc7914</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
@@ -84,12 +84,12 @@ Table of Contents
6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
- 8. Determining the Root Zone and Zone Governance . . . . . . . . 19
+ 8. Determining the Root Zone and Zone Governance . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . 23
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
@@ -1041,23 +1041,23 @@ Internet-Draft The GNU Name System November 2019
A single pass in the proof-of-work algorithm is defined as follows:
- skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
- skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", skey)
- enc := AES (skey, skey_iv, REVDAT)
- REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+ DK := scrypt (P := REV)
+ IV := IVderive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", DK)
+ EREV := AES (DK, IV, REV) /* TODO this is more complex */
+ REVDATA := scrypt(P := enc)
Figure 15
- The above function is called with different values for the "NONCE" in
- "REVDAT" until the amount of leading zeroes is greater or equal 25.
+ where "scrypt" is the scrypt algorithm as defined in [RFC7914] with
+ the following parameters set:
+
+ S := "gnunet-revocation-proof-of-work" /* Salt */
+ N := 1 /* CPU memory cost parameter TODO spec says >1!!! */
+ r := 8 /* Block size */
+ p := 2 /* Parallelization parameter */
+ dkLen := 512 /* Intended output length */
-8. Determining the Root Zone and Zone Governance
- The resolution of a GNS name must start in a given start zone
- indicated to the resolver using any public zone key. The local
- resolver may have a local start zone configured/hard-coded which
- points to a local or remote start zone key. A resolver client may
- also determine the start zone from the suffix of the name given for
@@ -1066,6 +1066,16 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 19]
Internet-Draft The GNU Name System November 2019
+ The above function is called with different values for the "NONCE" in
+ "REVDAT" until the amount of leading zeroes is greater or equal 25.
+
+8. Determining the Root Zone and Zone Governance
+
+ The resolution of a GNS name must start in a given start zone
+ indicated to the resolver using any public zone key. The local
+ resolver may have a local start zone configured/hard-coded which
+ points to a local or remote start zone key. A resolver client may
+ also determine the start zone from the suffix of the name given for
resolution or using information retrieved out of band. The
governance model of any zone is at the sole discretion of the zone
owner. However, the choice of start zone(s) is at the sole
@@ -1098,6 +1108,20 @@ Internet-Draft The GNU Name System November 2019
locally managed zone matches the suffix of the name to be resolved,
resolution SHOULD start from the respective local zone:
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 20]
+
+Internet-Draft The GNU Name System November 2019
+
+
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1114,14 +1138,6 @@ Internet-Draft The GNU Name System November 2019
".". If multiple suffixes match the name to resolve, the longest
matching suffix MUST BE used. The suffix length of two results
cannot be equal, as this would indicate a misconfiguration. If both
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 20]
-
-Internet-Draft The GNU Name System November 2019
-
-
a locally managed zone and a configuration entry exist for the same
suffix, the locally managed zone MUST have priority.
@@ -1155,6 +1171,13 @@ Internet-Draft The GNU Name System November 2019
f89333903b284fe8
1878bf47f3b39da0
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 21]
+
+Internet-Draft The GNU Name System November 2019
+
+
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
@@ -1171,13 +1194,6 @@ Internet-Draft The GNU Name System November 2019
6668e9f684f4dc33
6d656b27392b0fee
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
d_h :=
01fb61f482c17633
77611c4c2509e0f3
@@ -1210,6 +1226,14 @@ Internet-Draft The GNU Name System November 2019
3425e8a811ae59d2
99e2747285d2a479
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 22]
+
+Internet-Draft The GNU Name System November 2019
+
+
TWOFISH_IV :=
071be189a9d236f9
b4a3654bb8c281d4
@@ -1226,14 +1250,6 @@ Internet-Draft The GNU Name System November 2019
00000000
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 22]
-
-Internet-Draft The GNU Name System November 2019
-
-
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
@@ -1265,6 +1281,15 @@ Internet-Draft The GNU Name System November 2019
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+Internet-Draft The GNU Name System November 2019
+
+
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1283,13 +1308,6 @@ Internet-Draft The GNU Name System November 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
@@ -1320,10 +1338,22 @@ Internet-Draft The GNU Name System November 2019
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 24]
+
+Internet-Draft The GNU Name System November 2019
+
+
[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>.
+ [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
+ Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
+ August 2016, <https://www.rfc-editor.org/info/rfc7914>.
+
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
@@ -1338,14 +1368,6 @@ Authors' Addresses
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 24]
-
-Internet-Draft The GNU Name System November 2019
-
-
Germany
Email: schanzen@gnunet.org
@@ -1375,26 +1397,4 @@ Internet-Draft The GNU Name System November 2019
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 25]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -899,48 +899,48 @@
</section>
<section anchor="record_processing" numbered="true" toc="default">
<name>Record Processing</name>
- <t>
+ <t>
Record processing occurs at the end of a single recursion. We assume
that the RRBLOCK has been cryptographically verified and decrypted.
At this point, we must first determine if we have received a valid
record set in the context of the name we are trying to resolve:
</t>
- <ol>
+ <ol>
<li>
Case 1:
If the remainder of the name to resolve is empty and the record set
does not consist of a PKEY, CNAME or DNS2GNS record, the record set
is the result and the recursion is concluded.
</li>
- <li>
- Case 2:
- If the name to be resolved is of the format
- "_SERVICE._PROTO" and the record set contains one or more matching BOX
- records, the records in the BOX records are the result and the recusion
- is concluded (<xref target="box_processing" />).
- </li>
+ <li>
+ Case 2:
+ If the name to be resolved is of the format
+ "_SERVICE._PROTO" and the record set contains one or more matching BOX
+ records, the records in the BOX records are the result and the recusion
+ is concluded (<xref target="box_processing" />).
+ </li>
<li>
Case 3:
If the remainder of the name to resolve is not empty and
- does not match the "_SERVICE._PROTO" syntax, then the current record set
+ does not match the "_SERVICE._PROTO" syntax, then the current record set
MUST consist of a single PKEY record
- (<xref target="pkey_processing" />),
- a single CNAME record
- (<xref target="cname_processing" />),
+ (<xref target="pkey_processing" />),
+ a single CNAME record
+ (<xref target="cname_processing" />),
or one or more GNS2DNS records
- (<xref target="gns2dns_processing" />),
- which are processed
- as described in the respective sections below.
- Otherwise, resolution fails
+ (<xref target="gns2dns_processing" />),
+ which are processed
+ as described in the respective sections below.
+ Otherwise, resolution fails
and the resolver MUST return an empty record set.
- Finally, after the recursion terminates, the client preferences
- for the record type SHOULD be considered. If a VPN record is found
- and the client requests an A or AAAA record, the VPN record
- SHOULD be converted (<xref target="vpn_processing" />)
- if possible.
- </li>
- </ol>
+ Finally, after the recursion terminates, the client preferences
+ for the record type SHOULD be considered. If a VPN record is found
+ and the client requests an A or AAAA record, the VPN record
+ SHOULD be converted (<xref target="vpn_processing" />)
+ if possible.
+ </li>
+ </ol>
<section anchor="pkey_processing" numbered="true" toc="default">
<name>PKEY</name>
<t>
@@ -999,17 +999,17 @@
record (<xref target="gnsrecords_leho" />) with a relative
expiration time of one hour.
</t>
- <t>
- GNS resolvers SHOULD offer a configuration
- option to disable DNS processing to avoid information leakage
- and provide a consistent security profile for all name resolutions.
- Such resolvers would return an empty record set upon encountering
- a GNS2DNS record during the recursion. However, if GNS2DNS records
- are encountered in the record set for the apex and a GNS2DNS record
- is expicitly requested by the application, such records MUST
- still be returned, even if DNS support is disabled by the
- GNS resolver configuration.
- </t>
+ <t>
+ GNS resolvers SHOULD offer a configuration
+ option to disable DNS processing to avoid information leakage
+ and provide a consistent security profile for all name resolutions.
+ Such resolvers would return an empty record set upon encountering
+ a GNS2DNS record during the recursion. However, if GNS2DNS records
+ are encountered in the record set for the apex and a GNS2DNS record
+ is expicitly requested by the application, such records MUST
+ still be returned, even if DNS support is disabled by the
+ GNS resolver configuration.
+ </t>
</section>
<section anchor="cname_processing" numbered="true" toc="default">
<name>CNAME</name>
@@ -1033,8 +1033,8 @@
In order to prevent infinite loops, the resolver MUST
implement loop detections or limit the number of recursive
resolution steps.
- <!-- Note: Martin: do we actually implement this in GNS today?
- Seems rather tricky to detect if we go via NSS... -->
+ <!-- Note: Martin: do we actually implement this in GNS today?
+ Seems rather tricky to detect if we go via NSS... -->
</t>
</section>
<section anchor="box_processing" numbered="true" toc="default">
@@ -1051,7 +1051,7 @@
<section anchor="vpn_processing" numbered="true" toc="default">
<name>VPN</name>
<t>
- At the end of the recursion,
+ At the end of the recursion,
if the queried record type is either A or AAAA and the retrieved
record set contains at least one VPN record, the resolver SHOULD
open a tunnel and return the IPv4 or IPv6 tunnel address,
@@ -1102,12 +1102,23 @@
</t>
<figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
- skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
- skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", skey)
- enc := AES (skey, skey_iv, REVDAT)
- REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+ DK := scrypt (P := REV)
+ IV := IVderive (salt="gnunet-revocation-proof-of-work", "gnunet-proof-of-work-iv", DK)
+ EREV := AES (DK, IV, REV) /* TODO this is more complex */
+ REVDATA := scrypt(P := enc)
+ ]]></artwork>
+ </figure>
+ <t>
+ where "scrypt" is the scrypt algorithm as defined in
+ <xref target="RFC7914" /> with the following parameters set:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ S := "gnunet-revocation-proof-of-work" /* Salt */
+ N := 1 /* CPU memory cost parameter TODO spec says >1!!! */
+ r := 8 /* Block size */
+ p := 2 /* Parallelization parameter */
+ dkLen := 512 /* Intended output length */
]]></artwork>
- </figure>
<t>
The above function is called with different values for the "NONCE" in
"REVDAT" until the amount of leading zeroes is greater or equal 25.
@@ -1122,7 +1133,7 @@
which points to a local or remote start zone key.
A resolver client may also determine the start zone from the
suffix of the name given for resolution or using information
- retrieved out of band.
+ retrieved out of band.
The governance model of any zone is at the sole discretion
of the zone owner. However, the choice of start zone(s) is at the sole
discretion of the local system administrator or user.
@@ -1132,14 +1143,14 @@
where root zone governance is centralized at the Internet Corporation
for Assigned Names and Numbers (ICANN).
In DNS terminology, GNS roughly follows the idea of a hyper-hyper
- local root zone deployment, with the difference that it is not
- expected that all deployments use the same local root zone.
+ local root zone deployment, with the difference that it is not
+ expected that all deployments use the same local root zone.
</t>
<t>
In the following, we give examples how a local client resolver SHOULD
discover the start zone. The process given is not exhaustive and
clients MAY suppliement it with other mechanisms or ignore it if the
- particular application requires a different process.
+ particular application requires a different process.
</t>
<t>
GNS clients SHOULD first try to interpret the top-level domain of
@@ -1156,11 +1167,11 @@
<t>
In GNS, users MAY own and manage their own zones.
Each local zone SHOULD be associated with a single GNS label,
- but users MAY choose to use longer names consisting of
- multiple labels.
+ but users MAY choose to use longer names consisting of
+ multiple labels.
If the name of a locally managed zone matches the suffix
- of the name to be resolved,
- resolution SHOULD start from the respective local zone:
+ of the name to be resolved,
+ resolution SHOULD start from the respective local zone:
</t>
<artwork name="" type="" align="left" alt=""><