diff options
Diffstat (limited to 'draft-schanzen-gns.xml')
-rw-r--r-- | draft-schanzen-gns.xml | 75 |
1 files changed, 38 insertions, 37 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index 9e2980b..1319dfc 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -139,8 +139,8 @@ | |||
139 | This is an important distinguishing factor from the Domain Name System | 139 | This is an important distinguishing factor from the Domain Name System |
140 | where root zone governance is centralized at the Internet Corporation | 140 | where root zone governance is centralized at the Internet Corporation |
141 | for Assigned Names and Numbers (ICANN). | 141 | for Assigned Names and Numbers (ICANN). |
142 | In DNS terminology, GNS roughly follows the idea of a hyper-hyper | 142 | In DNS terminology, GNS roughly follows the idea of a hyperlocal root |
143 | local root zone deployment, with the difference that it is not | 143 | zone deployment, with the difference that it is not |
144 | expected that all deployments use the same local root zone. | 144 | expected that all deployments use the same local root zone. |
145 | </t> | 145 | </t> |
146 | <t> | 146 | <t> |
@@ -168,9 +168,10 @@ | |||
168 | <t> | 168 | <t> |
169 | In GNS, any user may create and manage one or more cryptographically | 169 | In GNS, any user may create and manage one or more cryptographically |
170 | secured zones (<xref target="zones"/>). | 170 | secured zones (<xref target="zones"/>). |
171 | A set of cryptographic functions which are determined by the zone type | 171 | Zones are uniquely identified by a zone key. |
172 | enable the creation of signatures for zone contents using blinded | 172 | Zone contents are signed using blinded private keys and |
173 | public/private key pairs and encryption of zone contents. | 173 | encrypted using derived secret keys. |
174 | The zone type determines the respectice set of cryptographic functions. | ||
174 | </t> | 175 | </t> |
175 | <t> | 176 | <t> |
176 | A zone can be populated with mappings from labels | 177 | A zone can be populated with mappings from labels |
@@ -278,7 +279,7 @@ | |||
278 | </dd> | 279 | </dd> |
279 | <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt> | 280 | <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt> |
280 | <dd> | 281 | <dd> |
281 | is a deterministic symmetric encryption function which encrypts the record | 282 | is a symmetric encryption function which encrypts the record |
282 | data based on key material derived from the zone key, | 283 | data based on key material derived from the zone key, |
283 | a label, a nonce and an expiration. | 284 | a label, a nonce and an expiration. |
284 | In order to leverage performance-enhancing caching features of certain | 285 | In order to leverage performance-enhancing caching features of certain |
@@ -287,9 +288,9 @@ | |||
287 | </dd> | 288 | </dd> |
288 | <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt> | 289 | <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt> |
289 | <dd> | 290 | <dd> |
290 | is a symmetric encryption function which decrypts the encrypted record | 291 | is a symmetric decryption function which decrypts the encrypted record |
291 | data based on key material derived from the zone key, | 292 | data based on key material derived from the zone key, |
292 | a label, a nonce an expiration. | 293 | a label, a nonce and an expiration. |
293 | </dd> | 294 | </dd> |
294 | <dt>Sign(d',message) -> signature</dt> | 295 | <dt>Sign(d',message) -> signature</dt> |
295 | <dd> | 296 | <dd> |
@@ -299,7 +300,7 @@ | |||
299 | <dt>Verify(zk',message,signature) -> valid</dt> | 300 | <dt>Verify(zk',message,signature) -> valid</dt> |
300 | <dd> | 301 | <dd> |
301 | is a function to verify the signature was created by | 302 | is a function to verify the signature was created by |
302 | the a private key d' derived from d and a label if | 303 | the private key d' derived from d and a label if |
303 | zk' was derived from the corresponding zone key | 304 | zk' was derived from the corresponding zone key |
304 | zk := Public-Keygen(d) and same label. | 305 | zk := Public-Keygen(d) and same label. |
305 | The function returns a boolean value of "TRUE" if the signature is valid, | 306 | The function returns a boolean value of "TRUE" if the signature is valid, |
@@ -404,7 +405,7 @@ zid := GNSCrockfordDecode(zkl) | |||
404 | For example, assuming a zkl of 130 characters, the encoding would be: | 405 | For example, assuming a zkl of 130 characters, the encoding would be: |
405 | </t> | 406 | </t> |
406 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 407 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
407 | zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | 408 | zTLD := zkl[126..129].zkl[63..125].zkl[0..62] |
408 | ]]></artwork> | 409 | ]]></artwork> |
409 | </section> | 410 | </section> |
410 | <section anchor="revocation" numbered="true" toc="default"> | 411 | <section anchor="revocation" numbered="true" toc="default"> |
@@ -494,8 +495,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
494 | <dt>ZONE KEY</dt> | 495 | <dt>ZONE KEY</dt> |
495 | <dd> | 496 | <dd> |
496 | is the 256-bit public key zk of the zone which is being revoked. | 497 | is the 256-bit public key zk of the zone which is being revoked. |
497 | The wire format of this value is defined in <xref target="RFC8032" />, | 498 | The wire format of this value is defined by the ZONE TYPE. |
498 | Section 5.1.5. | ||
499 | </dd> | 499 | </dd> |
500 | </dl> | 500 | </dl> |
501 | <t> | 501 | <t> |
@@ -567,7 +567,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
567 | </dd> | 567 | </dd> |
568 | <dt>TTL</dt> | 568 | <dt>TTL</dt> |
569 | <dd> | 569 | <dd> |
570 | denotes the relative 64-bit time to live of of the record in | 570 | denotes the relative 64-bit time to live of the record in |
571 | microseconds also in network byte order. This field is informational | 571 | microseconds also in network byte order. This field is informational |
572 | for a verifier. The verifier may discard revocation if the TTL | 572 | for a verifier. The verifier may discard revocation if the TTL |
573 | indicates that it is already expired. However, the actual TTL of the | 573 | indicates that it is already expired. However, the actual TTL of the |
@@ -645,17 +645,17 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
645 | in order: | 645 | in order: |
646 | </t> | 646 | </t> |
647 | <ol> | 647 | <ol> |
648 | <li>The current time MUST be between TIMESTAMP and | ||
649 | TIMESTAMP+TTL.</li> | ||
650 | <li>The signature MUST match the public key.</li> | 648 | <li>The signature MUST match the public key.</li> |
651 | <li>The set of POW values MUST NOT contain duplicates.</li> | 649 | <li>The set of POW values MUST NOT contain duplicates.</li> |
652 | <li>The average number of leading zeroes resulting from the provided | 650 | <li>The average number of leading zeroes resulting from the provided |
653 | POW values D' MUST be greater than D.</li> | 651 | POW values D' MUST be greater than and not equal to D.</li> |
654 | <li>The validation period (TTL) of the revocation is calculated as | 652 | <li>The validation period (TTL) of the revocation is calculated as |
655 | (D'-D) * EPOCH * 1.1. The EPOCH is extended by | 653 | (D'-D) * EPOCH * 1.1. The EPOCH is extended by |
656 | 10% in order to deal with unsynchronized clocks. | 654 | 10% in order to deal with unsynchronized clocks. |
657 | The TTL added on top of the TIMESTAMP yields the | 655 | The TTL added on top of the TIMESTAMP yields the |
658 | expiration date.</li> | 656 | expiration date.</li> |
657 | <li>The current time MUST be between TIMESTAMP and | ||
658 | TIMESTAMP+TTL.</li> | ||
659 | </ol> | 659 | </ol> |
660 | </section> | 660 | </section> |
661 | 661 | ||
@@ -803,7 +803,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
803 | delegate to. | 803 | delegate to. |
804 | A PKEY record MUST be the only record under a label. No other | 804 | A PKEY record MUST be the only record under a label. No other |
805 | records are allowed. The PKEY DATA entry wire format can be found | 805 | records are allowed. The PKEY DATA entry wire format can be found |
806 | found in <xref target="figure_pkeyrecord"/>. | 806 | in <xref target="figure_pkeyrecord"/>. |
807 | </t> | 807 | </t> |
808 | <figure anchor="figure_pkeyrecord"> | 808 | <figure anchor="figure_pkeyrecord"> |
809 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 809 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
@@ -857,7 +857,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
857 | </dd> | 857 | </dd> |
858 | <dt>L</dt> | 858 | <dt>L</dt> |
859 | <dd> | 859 | <dd> |
860 | is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. | 860 | is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. |
861 | </dd> | 861 | </dd> |
862 | </dl> | 862 | </dl> |
863 | <t> | 863 | <t> |
@@ -873,7 +873,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62] | |||
873 | zk := d * G | 873 | zk := d * G |
874 | PRK_h := HKDF-Extract ("key-derivation", zk) | 874 | PRK_h := HKDF-Extract ("key-derivation", zk) |
875 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 875 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
876 | d' := h * d mod L | 876 | d' := (h * d) mod L |
877 | ]]></artwork> | 877 | ]]></artwork> |
878 | <t> | 878 | <t> |
879 | Equally, given a label, the output zk' of the ZKDF-Public(zk,label) function is | 879 | Equally, given a label, the output zk' of the ZKDF-Public(zk,label) function is |
@@ -882,7 +882,7 @@ d' := h * d mod L | |||
882 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 882 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
883 | PRK_h := HKDF-Extract ("key-derivation", zk) | 883 | PRK_h := HKDF-Extract ("key-derivation", zk) |
884 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 884 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
885 | zk' := h mod L * zk | 885 | zk' := (h mod L) * zk |
886 | ]]></artwork> | 886 | ]]></artwork> |
887 | <t> | 887 | <t> |
888 | The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in | 888 | The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in |
@@ -909,8 +909,8 @@ zk' := h mod L * zk | |||
909 | as defined in <xref target="MODES" /> (CTR-AES-256): | 909 | as defined in <xref target="MODES" /> (CTR-AES-256): |
910 | </t> | 910 | </t> |
911 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 911 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
912 | DATA := CTR-AES256(K, IV, CIPHERTEXT) | ||
913 | CIPHERTEXT := CTR-AES256(K, IV, DATA) | 912 | CIPHERTEXT := CTR-AES256(K, IV, DATA) |
913 | DATA := CTR-AES256(K, IV, CIPHERTEXT) | ||
914 | ]]></artwork> | 914 | ]]></artwork> |
915 | <t> | 915 | <t> |
916 | The key K and counter IV are derived from | 916 | The key K and counter IV are derived from |
@@ -1028,7 +1028,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8) | |||
1028 | </dd> | 1028 | </dd> |
1029 | <dt>L</dt> | 1029 | <dt>L</dt> |
1030 | <dd> | 1030 | <dd> |
1031 | is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. | 1031 | is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. |
1032 | </dd> | 1032 | </dd> |
1033 | </dl> | 1033 | </dl> |
1034 | <t> | 1034 | <t> |
@@ -1047,7 +1047,7 @@ PRK_h := HKDF-Extract ("key-derivation", zk) | |||
1047 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 1047 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
1048 | h[31] &= 7 | 1048 | h[31] &= 7 |
1049 | a1 := a / 8 /* 8 is the cofactor of Curve25519 */ | 1049 | a1 := a / 8 /* 8 is the cofactor of Curve25519 */ |
1050 | a2 := h * a1 mod L | 1050 | a2 := (h * a1) mod L |
1051 | a' = a2 * 8 /* 8 is the cofactor of Curve25519 */ | 1051 | a' = a2 * 8 /* 8 is the cofactor of Curve25519 */ |
1052 | ]]></artwork> | 1052 | ]]></artwork> |
1053 | <t> | 1053 | <t> |
@@ -1121,13 +1121,13 @@ S * G == R + SHA512(R, zk', M) * zk' | |||
1121 | (XSalsa20-Poly1305): | 1121 | (XSalsa20-Poly1305): |
1122 | </t> | 1122 | </t> |
1123 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1123 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1124 | DATA := XSalsa20(K, IV, CIPHERTEXT) | 1124 | CIPHERTEXT := XSalsa20-Poly1305(K, IV, DATA) |
1125 | CIPHERTEXT := XSalsa20(K, IV, DATA) = CIPHERTEXT | TAG | 1125 | DATA := XSalsa20-Poly1305(K, IV, CIPHERTEXT) |
1126 | ]]></artwork> | 1126 | ]]></artwork> |
1127 | <t> | 1127 | <t> |
1128 | The result of the XSalsa20 encryption function is the encrypted | 1128 | The result of the XSalsa20-Poly1305 encryption function is the encrypted |
1129 | ciphertext concatenated with the 128-bit authentication | 1129 | ciphertext concatenated with the 128-bit authentication |
1130 | tag TAG. | 1130 | tag. |
1131 | Accordingly, the length of encrypted data equals the length of the | 1131 | Accordingly, the length of encrypted data equals the length of the |
1132 | data plus the 16 bytes of the authentication tag. | 1132 | data plus the 16 bytes of the authentication tag. |
1133 | </t> | 1133 | </t> |
@@ -1363,8 +1363,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8) | |||
1363 | The GNUnet Tunnel Service record is used by | 1363 | The GNUnet Tunnel Service record is used by |
1364 | applications to establish a tunnel between two peers in the | 1364 | applications to establish a tunnel between two peers in the |
1365 | peer-to-peer network (see <xref target="GNUnet"/>). | 1365 | peer-to-peer network (see <xref target="GNUnet"/>). |
1366 | In order to facilitate the use of such tunnels, the | 1366 | The GTS record serves as an example of how resolvers may automatically |
1367 | The GTS record serves as an example to how resolvers may automatically | ||
1368 | initiate tunnel establishment and provide IP address information in the | 1367 | initiate tunnel establishment and provide IP address information in the |
1369 | resolution process as specified in <xref target="resolution"/>. | 1368 | resolution process as specified in <xref target="resolution"/>. |
1370 | </t> | 1369 | </t> |
@@ -1631,7 +1630,8 @@ q := SHA512 (HDKD-Public(zk, label)) | |||
1631 | <t> | 1630 | <t> |
1632 | Names in GNS are resolved by recursively querying the record storage. | 1631 | Names in GNS are resolved by recursively querying the record storage. |
1633 | Recursive in this context means that a resolver does not provide | 1632 | Recursive in this context means that a resolver does not provide |
1634 | iterative results for a query (as is the case with iterative DNS resolution). | 1633 | iterative results for a query. |
1634 | <!--(as is the case with iterative DNS resolution). REMOVED --> | ||
1635 | Instead, it MUST respond to a resolution request with either the | 1635 | Instead, it MUST respond to a resolution request with either the |
1636 | requested resource record or an error message in case the resolution | 1636 | requested resource record or an error message in case the resolution |
1637 | fails. | 1637 | fails. |
@@ -1641,7 +1641,7 @@ q := SHA512 (HDKD-Public(zk, label)) | |||
1641 | <t> | 1641 | <t> |
1642 | GNS resolution of a name must start in a given starting zone indicated using | 1642 | GNS resolution of a name must start in a given starting zone indicated using |
1643 | a zone key. | 1643 | a zone key. |
1644 | Details on how the starting zone may be determined is discussed in | 1644 | Details on how the starting zone may be determined are discussed in |
1645 | <xref target="governance" />. | 1645 | <xref target="governance" />. |
1646 | </t> | 1646 | </t> |
1647 | <t> | 1647 | <t> |
@@ -1862,7 +1862,7 @@ example.com = zk2 | |||
1862 | to the remainder of the name to be resolved, and | 1862 | to the remainder of the name to be resolved, and |
1863 | resolved by querying the DNS name server(s). As the DNS servers | 1863 | resolved by querying the DNS name server(s). As the DNS servers |
1864 | specified are possibly authoritative DNS servers, the GNS resolver MUST | 1864 | specified are possibly authoritative DNS servers, the GNS resolver MUST |
1865 | support recursive resolution and MUST NOT delegate this to the | 1865 | support recursive DNS resolution and MUST NOT delegate this to the |
1866 | authoritative DNS servers. | 1866 | authoritative DNS servers. |
1867 | The first successful recursive name resolution result | 1867 | The first successful recursive name resolution result |
1868 | is returned to the client. | 1868 | is returned to the client. |
@@ -1961,9 +1961,9 @@ NICK: eve | |||
1961 | <t> | 1961 | <t> |
1962 | In this example, the returned NICK record is non-supplemental. | 1962 | In this example, the returned NICK record is non-supplemental. |
1963 | For the client, this means that the NICK belongs to the zone | 1963 | For the client, this means that the NICK belongs to the zone |
1964 | "alice.doe" and is published under the empty label along with an A | 1964 | "alice.example" and is published under the empty label along with an A |
1965 | record. The NICK record should be interpreted as: The zone defined by | 1965 | record. The NICK record should be interpreted as: The zone defined by |
1966 | "alice.doe" wants to be referred to as "eve". | 1966 | "alice.example" wants to be referred to as "eve". |
1967 | In contrast, consider the following: | 1967 | In contrast, consider the following: |
1968 | </t> | 1968 | </t> |
1969 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1969 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
@@ -2055,7 +2055,7 @@ NICK: john (Supplemental) | |||
2055 | monotonically. | 2055 | monotonically. |
2056 | For blocks with absolute expiration times, the implementation | 2056 | For blocks with absolute expiration times, the implementation |
2057 | MUST ensure that the expiration time is modified when the record | 2057 | MUST ensure that the expiration time is modified when the record |
2058 | data changes. For example. the expiration time may be increased | 2058 | data changes. For example, the expiration time may be increased |
2059 | by a single microsecond. | 2059 | by a single microsecond. |
2060 | </t> | 2060 | </t> |
2061 | </section> | 2061 | </section> |
@@ -2088,8 +2088,9 @@ NICK: john (Supplemental) | |||
2088 | pre-calculated and is still available). | 2088 | pre-calculated and is still available). |
2089 | Zone administrators, and for GNS this includes end-users, are | 2089 | Zone administrators, and for GNS this includes end-users, are |
2090 | required to responsibly and diligently protect their cryptographic | 2090 | required to responsibly and diligently protect their cryptographic |
2091 | keys. Offline signing is in principle possible, but GNS does not | 2091 | keys. |
2092 | support separate zone signing and key-signing keys | 2092 | GNS supports offline signing of records. |
2093 | It does not support separate zone signing and key-signing keys | ||
2093 | (as in <xref target="RFC6781" />) in order to provide usable security. | 2094 | (as in <xref target="RFC6781" />) in order to provide usable security. |
2094 | </t> | 2095 | </t> |
2095 | <t> | 2096 | <t> |