diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2022-02-04 19:01:05 +0100 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2022-02-04 19:01:05 +0100 |
commit | 41437cd20299d6c7c6b90841e143e338bd8b5440 (patch) | |
tree | 8fc44a9def7e07a4a1fa3a8005c04eac34cb2182 | |
parent | 6a39c87f29c77328cf016908a290d9ea379ae4af (diff) | |
download | lsd0001-41437cd20299d6c7c6b90841e143e338bd8b5440.tar.gz lsd0001-41437cd20299d6c7c6b90841e143e338bd8b5440.zip |
review with bfix
-rw-r--r-- | draft-schanzen-gns.xml | 165 |
1 files changed, 98 insertions, 67 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index 26d0d70..640e135 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -190,7 +190,7 @@ | |||
190 | A GNS label is a label as defined in <xref target="RFC8499"/>. | 190 | A GNS label is a label as defined in <xref target="RFC8499"/>. |
191 | Within this document, labels are always assumed to be strings of | 191 | Within this document, labels are always assumed to be strings of |
192 | UTF-8 characters <xref target="RFC8499"/> with a maximum length of | 192 | UTF-8 characters <xref target="RFC8499"/> with a maximum length of |
193 | 63 bytes. When hashed, labels MUST be canonicalized using | 193 | 63 bytes. Labels MUST be canonicalized using |
194 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | 194 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. |
195 | </dd> | 195 | </dd> |
196 | <dt>Name</dt> | 196 | <dt>Name</dt> |
@@ -200,7 +200,7 @@ | |||
200 | The labels in a name are separated using the character "." (dot). | 200 | The labels in a name are separated using the character "." (dot). |
201 | Names, like labels, are encoded in UTF-8. | 201 | Names, like labels, are encoded in UTF-8. |
202 | </dd> | 202 | </dd> |
203 | <dt>Top-Level Domain</dt> | 203 | <dt>Top-Level Domain</dt> <!--FIXME shall we call this TLZ? --> |
204 | <dd> | 204 | <dd> |
205 | The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). | 205 | The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). |
206 | A GNS TLD may consist of one or more labels. | 206 | A GNS TLD may consist of one or more labels. |
@@ -395,6 +395,9 @@ | |||
395 | <dd> | 395 | <dd> |
396 | is a function to sign a message (typically encrypted record data) using the (blinded) private | 396 | is a function to sign a message (typically encrypted record data) using the (blinded) private |
397 | key d (d'), yielding an unforgable cryptographic signature. | 397 | key d (d'), yielding an unforgable cryptographic signature. |
398 | In order to leverage performance-enhancing caching features of certain | ||
399 | underlying storages, in particular DHTs, a deterministic signature | ||
400 | scheme is recommended. | ||
398 | </dd> | 401 | </dd> |
399 | <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt> | 402 | <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt> |
400 | <dd> | 403 | <dd> |
@@ -497,6 +500,7 @@ ztype|zkey := GNSCrockfordDecode(zkl) | |||
497 | to subsequently determine how many labels the zTLD should span. | 500 | to subsequently determine how many labels the zTLD should span. |
498 | For example, assuming a zkl of 130 characters, the encoding would be: | 501 | For example, assuming a zkl of 130 characters, the encoding would be: |
499 | </t> | 502 | </t> |
503 | <!-- FIXME: Is this really really necessary? Really? --> | ||
500 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 504 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
501 | zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | 505 | zTLD := zkl[126..129].zkl[63..125].zkl[0..62] |
502 | ]]></artwork> | 506 | ]]></artwork> |
@@ -694,10 +698,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
694 | (see <xref target="zones" />). | 698 | (see <xref target="zones" />). |
695 | </dd> | 699 | </dd> |
696 | </dl> | 700 | </dl> |
701 | <!-- FIXME Do we really need a purpose? --> | ||
697 | <t> | 702 | <t> |
698 | The signature over the public key covers a 32-bit pseudo header | 703 | The signature over the public key covers a 32-bit header |
699 | conceptually prefixed to the public key. The pseudo header includes | 704 | prefixed to the timestamp and public key fields. |
700 | the key length and signature purpose. The wire format is illustrated | 705 | The header includes the key length and signature purpose. |
706 | The wire format is illustrated | ||
701 | in <xref target="figure_revsigwithpseudo"/>. | 707 | in <xref target="figure_revsigwithpseudo"/>. |
702 | </t> | 708 | </t> |
703 | <figure anchor="figure_revsigwithpseudo"> | 709 | <figure anchor="figure_revsigwithpseudo"> |
@@ -767,7 +773,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
767 | <name>Resource Records</name> | 773 | <name>Resource Records</name> |
768 | <t> | 774 | <t> |
769 | A GNS implementer SHOULD provide a mechanism to create and manage resource | 775 | A GNS implementer SHOULD provide a mechanism to create and manage resource |
770 | records for local zones. A local zone is established by selecting a | 776 | records for local zones. A new local zone is established by selecting a |
771 | zone type and creating a zone key pair. | 777 | zone type and creating a zone key pair. |
772 | As records may be added to each zone by its owner, a (local) persistence | 778 | As records may be added to each zone by its owner, a (local) persistence |
773 | mechanism such as a database for resource records and zones SHOULD be provided. | 779 | mechanism such as a database for resource records and zones SHOULD be provided. |
@@ -822,7 +828,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
822 | </dd> | 828 | </dd> |
823 | <dt>DATA</dt> | 829 | <dt>DATA</dt> |
824 | <dd> | 830 | <dd> |
825 | the variable-length resource record data payload. The contents are defined | 831 | the variable-length resource record data payload. The content is defined |
826 | by the | 832 | by the |
827 | respective type of the resource record. | 833 | respective type of the resource record. |
828 | </dd> | 834 | </dd> |
@@ -886,20 +892,23 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
886 | MAY BE a valid choice if some zone delegation record types have been | 892 | MAY BE a valid choice if some zone delegation record types have been |
887 | determined to be cryptographically insecure, or if an application has | 893 | determined to be cryptographically insecure, or if an application has |
888 | reasons to not support delegation to DNS for reasons such as complexity | 894 | reasons to not support delegation to DNS for reasons such as complexity |
889 | or security. Zone delegation records MUST NOT be stored and published | 895 | or security. Zone delegation records MUST NOT be stored and published |
890 | under the empty label. | 896 | under the empty label. |
897 | <!-- FIXME: Empty label and apex label are not well defined --> | ||
898 | A zone delegation record type value is the same as the respective ztype | ||
899 | value. | ||
900 | The ztype defines the cryptographic primitives for the zone that is | ||
901 | being delegated to. | ||
902 | A zone delegation resource record payload contains the public key of | ||
903 | the zone to delegate to. | ||
904 | A zone delegation record MUST be the only record under a label. | ||
905 | No other records are allowed. | ||
891 | </t> | 906 | </t> |
892 | <section anchor="gnsrecords_pkey" numbered="true" toc="default"> | 907 | <section anchor="gnsrecords_pkey" numbered="true" toc="default"> |
893 | <name>PKEY</name> | 908 | <name>PKEY</name> |
894 | <t>In GNS, a delegation of a label to a zone of type "PKEY" is | 909 | <t> |
895 | represented through a PKEY record. The PKEY number is a ztype | 910 | In GNS, a delegation of a label to a zone of type "PKEY" is |
896 | and thus also implies the cryptosystem for the zone that | 911 | represented through a PKEY record. The PKEY DATA entry wire format can be found in <xref target="figure_pkeyrecord"/>. |
897 | is being delegated to. | ||
898 | A PKEY resource record contains the public key of the zone to | ||
899 | delegate to. | ||
900 | A PKEY record MUST be the only record under a label. No other | ||
901 | records are allowed. The PKEY DATA entry wire format can be found | ||
902 | in <xref target="figure_pkeyrecord"/>. | ||
903 | </t> | 912 | </t> |
904 | <figure anchor="figure_pkeyrecord"> | 913 | <figure anchor="figure_pkeyrecord"> |
905 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 914 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
@@ -916,14 +925,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
916 | <dl> | 925 | <dl> |
917 | <dt>PUBLIC KEY</dt> | 926 | <dt>PUBLIC KEY</dt> |
918 | <dd> | 927 | <dd> |
919 | A 256-bit ECDSA zone key. | 928 | A 256-bit Ed25519 public key. |
920 | </dd> | 929 | </dd> |
921 | </dl> | 930 | </dl> |
922 | 931 | ||
923 | <t> | 932 | <t> |
924 | For PKEY zones the zone key material is derived using the | 933 | For PKEY zones the zone key material is derived using the |
925 | curve parameters of the twisted edwards representation | 934 | curve parameters of the twisted Edwards representation |
926 | of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519) | 935 | of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519) |
927 | with the ECDSA scheme <xref target="RFC6979" />. | 936 | with the ECDSA scheme <xref target="RFC6979" />. |
928 | Consequently, we use the following naming convention for our | 937 | Consequently, we use the following naming convention for our |
929 | cryptographic primitives for PKEY zones: | 938 | cryptographic primitives for PKEY zones: |
@@ -931,11 +940,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
931 | <dl> | 940 | <dl> |
932 | <dt>d</dt> | 941 | <dt>d</dt> |
933 | <dd> | 942 | <dd> |
934 | is a 256-bit ECDSA private key. | 943 | is a 256-bit Ed25519 private key (private scalar). |
935 | </dd> | 944 | </dd> |
936 | <dt>zk</dt> | 945 | <dt>zk</dt> |
937 | <dd> | 946 | <dd> |
938 | is the ECDSA public zone key corresponding to d. | 947 | is the Ed25519 public zone key corresponding to d. |
939 | </dd> | 948 | </dd> |
940 | <dt>p</dt> | 949 | <dt>p</dt> |
941 | <dd> | 950 | <dd> |
@@ -959,7 +968,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] | |||
959 | </dd> | 968 | </dd> |
960 | </dl> | 969 | </dl> |
961 | <t> | 970 | <t> |
962 | The zone type and zone key of a PKEY are 32 + 4 bytes in length. This means that | 971 | The zone type and zone key of a PKEY are 4 + 32 bytes in length. This means that |
963 | a zTLD will always fit into a single label and does | 972 | a zTLD will always fit into a single label and does |
964 | not need any further conversion. | 973 | not need any further conversion. |
965 | </t> | 974 | </t> |
@@ -1061,23 +1070,30 @@ S-Encrypt(zk,label,expiration,message): | |||
1061 | K := HKDF-Expand (PRK_k, label, 256 / 8); | 1070 | K := HKDF-Expand (PRK_k, label, 256 / 8); |
1062 | NONCE := HKDF-Expand (PRK_n, label, 32 / 8) | 1071 | NONCE := HKDF-Expand (PRK_n, label, 32 / 8) |
1063 | IV := NONCE | expiration | 0x0000000000000001 | 1072 | IV := NONCE | expiration | 0x0000000000000001 |
1064 | CIPHERTEXT := CTR-AES256(K, IV, DATA) | 1073 | return CTR-AES256(K, IV, DATA) |
1065 | DATA := CTR-AES256(K, IV, CIPHERTEXT) | ||
1066 | ]]></artwork> | 1074 | ]]></artwork> |
1067 | </figure> | 1075 | </figure> |
1068 | <t>The PKEY S-Encrypt Procedure.</t> | 1076 | <t>The PKEY S-Encrypt Procedure.</t> |
1077 | <figure anchor="figure_sdec_pkey"> | ||
1078 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1079 | S-Decrypt(zk,label,expiration,ciphertext): | ||
1080 | PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) | ||
1081 | PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) | ||
1082 | K := HKDF-Expand (PRK_k, label, 256 / 8); | ||
1083 | NONCE := HKDF-Expand (PRK_n, label, 32 / 8) | ||
1084 | IV := NONCE | expiration | 0x0000000000000001 | ||
1085 | return CTR-AES256(K, IV, ciphertext) | ||
1086 | ]]></artwork> | ||
1087 | </figure> | ||
1088 | <t>The PKEY S-Decrypt Procedure.</t> | ||
1089 | <!-- FIXME: Explicit precedures would be nicer Appendix?--> | ||
1069 | </section> | 1090 | </section> |
1070 | <section anchor="gnsrecords_edkey" numbered="true" toc="default"> | 1091 | <section anchor="gnsrecords_edkey" numbered="true" toc="default"> |
1071 | <name>EDKEY</name> | 1092 | <name>EDKEY</name> |
1072 | <t> | 1093 | <t> |
1073 | In GNS, a delegation of a label to a zone of type "EDKEY" is | 1094 | In GNS, a delegation of a label to a zone of type "EDKEY" is |
1074 | represented through a EDKEY record. The EDKEY number is a | 1095 | represented through a EDKEY record. |
1075 | ztype and thus also implies the cryptosystem for the zone that | 1096 | The EDKEY DATA entry wire format |
1076 | is being delegated to. | ||
1077 | An EDKEY resource record contains the public key of the zone to | ||
1078 | delegate to. | ||
1079 | A EDKEY record MUST be the only record under a label. No other | ||
1080 | records are allowed. The EDKEY DATA entry wire format | ||
1081 | is illustrated in <xref target="figure_edkeyrecord"/>. | 1097 | is illustrated in <xref target="figure_edkeyrecord"/>. |
1082 | </t> | 1098 | </t> |
1083 | <figure anchor="figure_edkeyrecord"> | 1099 | <figure anchor="figure_edkeyrecord"> |
@@ -1101,11 +1117,12 @@ S-Encrypt(zk,label,expiration,message): | |||
1101 | <t> | 1117 | <t> |
1102 | For EDKEY zones the zone key material is derived using the | 1118 | For EDKEY zones the zone key material is derived using the |
1103 | curve parameters of the twisted edwards representation | 1119 | curve parameters of the twisted edwards representation |
1104 | of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519) | 1120 | of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519) |
1105 | with the Ed25519-SHA-512 scheme <xref target="ed25519" />. | 1121 | with the Ed25519-SHA-512 scheme <xref target="ed25519" />. |
1106 | Consequently, we use the following naming convention for our | 1122 | Consequently, we use the following naming convention for our |
1107 | cryptographic primitives for EDKEY zones: | 1123 | cryptographic primitives for EDKEY zones: |
1108 | </t> | 1124 | </t> |
1125 | <!-- Check if we want to use RFC8032 instead of paper ed25519 --> | ||
1109 | <dl> | 1126 | <dl> |
1110 | <dt>d</dt> | 1127 | <dt>d</dt> |
1111 | <dd> | 1128 | <dd> |
@@ -1149,7 +1166,7 @@ S-Encrypt(zk,label,expiration,message): | |||
1149 | </dd> | 1166 | </dd> |
1150 | </dl> | 1167 | </dl> |
1151 | <t> | 1168 | <t> |
1152 | The zone type and zone key of an EDKEY are 32 + 4 bytes in length. This means that | 1169 | The zone type and zone key of an EDKEY are 4 + 32 bytes in length. This means that |
1153 | a zTLD will always fit into a single label and does | 1170 | a zTLD will always fit into a single label and does |
1154 | not need any further conversion. | 1171 | not need any further conversion. |
1155 | </t> | 1172 | </t> |
@@ -1163,9 +1180,9 @@ zk := a * G | |||
1163 | PRK_h := HKDF-Extract ("key-derivation", zk) | 1180 | PRK_h := HKDF-Extract ("key-derivation", zk) |
1164 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 1181 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
1165 | h[31] &= 7 | 1182 | h[31] &= 7 |
1166 | a1 := a / 8 /* 8 is the cofactor of Curve25519 */ | 1183 | a1 := a >> 3 |
1167 | a2 := (h * a1) mod L | 1184 | a2 := (h * a1) mod L |
1168 | a' = a2 * 8 /* 8 is the cofactor of Curve25519 */ | 1185 | a' = a2 << 3 |
1169 | ]]></artwork> | 1186 | ]]></artwork> |
1170 | <t> | 1187 | <t> |
1171 | Equally, given a label, the output of the ZKDF-Public function is | 1188 | Equally, given a label, the output of the ZKDF-Public function is |
@@ -1182,9 +1199,10 @@ zk' := h * zk | |||
1182 | multiplication for the constructions above to protect against | 1199 | multiplication for the constructions above to protect against |
1183 | timing attacks. Otherwise, timing attacks may leak private key | 1200 | timing attacks. Otherwise, timing attacks may leak private key |
1184 | material if an attacker can predict when a system starts the | 1201 | material if an attacker can predict when a system starts the |
1185 | publication process. Also, implementers | 1202 | publication process. |
1203 | <!--Also, implementers | ||
1186 | MUST ensure that the private key a is an ed25519 private key | 1204 | MUST ensure that the private key a is an ed25519 private key |
1187 | and specifically that "a[0] & 7 == 0" holds. | 1205 | and specifically that "a[0] & 7 == 0" holds.--> |
1188 | </t> | 1206 | </t> |
1189 | <t> | 1207 | <t> |
1190 | The EDKEY cryptosystem uses a | 1208 | The EDKEY cryptosystem uses a |
@@ -1222,6 +1240,10 @@ zk' := h * zk | |||
1222 | of the R value of the signature, ensuring that it is never reused | 1240 | of the R value of the signature, ensuring that it is never reused |
1223 | for two different derivation paths or messages. | 1241 | for two different derivation paths or messages. |
1224 | </t> | 1242 | </t> |
1243 | <!-- Blinded key signatures need a different method signature | ||
1244 | FIXME Should we use a' | ||
1245 | nonce := SHA-256 (a')? | ||
1246 | --> | ||
1225 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1247 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1226 | dh := SHA-512 (d) | 1248 | dh := SHA-512 (d) |
1227 | nonce := SHA-256 (dh[32..63] | h) | 1249 | nonce := SHA-256 (dh[32..63] | h) |
@@ -1504,6 +1526,8 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8) | |||
1504 | <dl> | 1526 | <dl> |
1505 | <dt>PROTO</dt> | 1527 | <dt>PROTO</dt> |
1506 | <dd> | 1528 | <dd> |
1529 | <!-- FIXME: Help Christian this is all wrong. | ||
1530 | RFC6895 is DNS. Also: SVC what are possible numbers? --> | ||
1507 | the 16-bit protocol number, e.g. 6 for tcp. | 1531 | the 16-bit protocol number, e.g. 6 for tcp. |
1508 | Note that values | 1532 | Note that values |
1509 | below 2^8 are reserved for allocation via IANA <xref target="RFC6895" />, | 1533 | below 2^8 are reserved for allocation via IANA <xref target="RFC6895" />, |
@@ -1792,7 +1816,10 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1792 | </t> | 1816 | </t> |
1793 | <t> | 1817 | <t> |
1794 | When GNS name resolution is requested, a desired record type MAY be | 1818 | When GNS name resolution is requested, a desired record type MAY be |
1795 | provided by the client. | 1819 | provided by the client to guide processing. |
1820 | <!-- FIXME: Is this still necessary? Clarify the purpose of the | ||
1821 | provided record type and normatively define that resolver MUST NOT | ||
1822 | filter? --> | ||
1796 | However, filtering of record sets according to the required record | 1823 | However, filtering of record sets according to the required record |
1797 | types MUST still be done by the client after the resource record set | 1824 | types MUST still be done by the client after the resource record set |
1798 | is retrieved. | 1825 | is retrieved. |
@@ -1800,10 +1827,11 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1800 | <section anchor="governance" numbered="true" toc="default"> | 1827 | <section anchor="governance" numbered="true" toc="default"> |
1801 | <name>Start Zones</name> | 1828 | <name>Start Zones</name> |
1802 | <t> | 1829 | <t> |
1830 | <!-- FIXME: This is a mess --> | ||
1803 | The resolution of a GNS name must start in a given start zone | 1831 | The resolution of a GNS name must start in a given start zone |
1804 | indicated to the resolution algorithm using any (public) zone key. | 1832 | indicated to the resolution algorithm using a (public) zone key. |
1805 | The local resolver may have one or more local start zones configured/hard-coded | 1833 | The local resolver may have one or more local start zones configured/hard-coded |
1806 | which point to a local or remote start zone public keys. | 1834 | which point to local or remote zone public keys. |
1807 | A resolver may also determine the start zone from the | 1835 | A resolver may also determine the start zone from the |
1808 | suffix of the name given for resolution, or using information | 1836 | suffix of the name given for resolution, or using information |
1809 | retrieved out of band. | 1837 | retrieved out of band. |
@@ -1824,9 +1852,8 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1824 | <t> | 1852 | <t> |
1825 | GNS clients MUST first try to interpret the top-level domain of | 1853 | GNS clients MUST first try to interpret the top-level domain of |
1826 | a GNS name as a zone key representation (i.e. a zTLD). | 1854 | a GNS name as a zone key representation (i.e. a zTLD). |
1827 | If the top-level domain is indicated to be a representation of | 1855 | If the top-level domain can be converted to a valid ztype and zone |
1828 | a zone key with a supported zone type value, the start zone of | 1856 | key value, the resulting zone key is used as the start zone: |
1829 | the resolution process is implicitly given by the suffix of the name: | ||
1830 | </t> | 1857 | </t> |
1831 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1858 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1832 | Example name: www.example.<zTLD> | 1859 | Example name: www.example.<zTLD> |
@@ -1909,9 +1936,9 @@ example.com = zk2 | |||
1909 | <name>Record Processing</name> | 1936 | <name>Record Processing</name> |
1910 | <t> | 1937 | <t> |
1911 | Record processing occurs once a well-formed block was decrypted. | 1938 | Record processing occurs once a well-formed block was decrypted. |
1912 | In record processing, only the valid records thus | 1939 | In record processing, only the valid records obtained are considered. |
1913 | obtained are considered. To filter records by validity, the resolver | 1940 | To filter records by validity, the resolver |
1914 | MUST at least checking the expiration time and the FLAGS of the | 1941 | MUST at least check the expiration time and the FLAGS of the |
1915 | respective record. In particular, FLAGS may exclude shadow and | 1942 | respective record. In particular, FLAGS may exclude shadow and |
1916 | supplemental records from being considered. | 1943 | supplemental records from being considered. |
1917 | If the resolver encounters a record with the CRITICAL flag set and | 1944 | If the resolver encounters a record with the CRITICAL flag set and |
@@ -2079,11 +2106,10 @@ example.com = zk2 | |||
2079 | If the remainder of the name to resolve is empty and we have | 2106 | If the remainder of the name to resolve is empty and we have |
2080 | received a record set containing only a single delegation record, the | 2107 | received a record set containing only a single delegation record, the |
2081 | recursion is continued with the record value as authoritative zone | 2108 | recursion is continued with the record value as authoritative zone |
2082 | and the empty apex label "@" as remaining name, except in the case | 2109 | and the empty apex label "@" as remaining name. |
2083 | where the desired record type as specified by the client | 2110 | Except in the case where the desired record type as specified by |
2084 | is equal to the ztype, in which | 2111 | the client is equal to the ztype, in which case the delegation |
2085 | case the delegation record is returned and the resolution is concluded without | 2112 | record is returned. |
2086 | resolving the empty apex label. | ||
2087 | </t> | 2113 | </t> |
2088 | </section> | 2114 | </section> |
2089 | <section anchor="nick_processing" numbered="true" toc="default"> | 2115 | <section anchor="nick_processing" numbered="true" toc="default"> |
@@ -2142,6 +2168,8 @@ NICK: john (Supplemental) | |||
2142 | <name>Internationalization and Character Encoding</name> | 2168 | <name>Internationalization and Character Encoding</name> |
2143 | <t> | 2169 | <t> |
2144 | All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />. | 2170 | All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />. |
2171 | Labels MUST be canonicalized using | ||
2172 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | ||
2145 | This does not include any DNS names found in DNS records, such as CNAME | 2173 | This does not include any DNS names found in DNS records, such as CNAME |
2146 | records, which are internationalized through the IDNA specifications | 2174 | records, which are internationalized through the IDNA specifications |
2147 | <xref target="RFC5890" />. | 2175 | <xref target="RFC5890" />. |
@@ -2184,7 +2212,7 @@ NICK: john (Supplemental) | |||
2184 | </t> | 2212 | </t> |
2185 | <t> | 2213 | <t> |
2186 | This document concerns itself with the selection of cryptographic | 2214 | This document concerns itself with the selection of cryptographic |
2187 | algorithms for use in GNS. | 2215 | algorithms used in GNS. |
2188 | The algorithms identified in this document are not known to be | 2216 | The algorithms identified in this document are not known to be |
2189 | broken (in the cryptographic sense) at the current time, and | 2217 | broken (in the cryptographic sense) at the current time, and |
2190 | cryptographic research so far leads us to believe that they are | 2218 | cryptographic research so far leads us to believe that they are |
@@ -2195,7 +2223,7 @@ NICK: john (Supplemental) | |||
2195 | </t> | 2223 | </t> |
2196 | <t> | 2224 | <t> |
2197 | In terms of crypto-agility, whenever the need for an updated cryptographic | 2225 | In terms of crypto-agility, whenever the need for an updated cryptographic |
2198 | scheme arises to, for example, replace ECDSA over Curve25519 for | 2226 | scheme arises to, for example, replace ECDSA over Ed25519 for |
2199 | PKEY records it may simply be introduced | 2227 | PKEY records it may simply be introduced |
2200 | through a new record type. Such a new record type may then replace | 2228 | through a new record type. Such a new record type may then replace |
2201 | the delegation record type for future records. | 2229 | the delegation record type for future records. |
@@ -2210,14 +2238,14 @@ NICK: john (Supplemental) | |||
2210 | <section anchor="security_cryptography" numbered="true" toc="default"> | 2238 | <section anchor="security_cryptography" numbered="true" toc="default"> |
2211 | <name>Cryptography</name> | 2239 | <name>Cryptography</name> |
2212 | <t> | 2240 | <t> |
2213 | GNS PKEY zone keys use ECDSA over Curve25519. | 2241 | GNS PKEY zone keys use ECDSA over Ed25519. |
2214 | This is an unconventional choice, | 2242 | This is an unconventional choice, |
2215 | as ECDSA is usually used with other curves. However, traditional | 2243 | as ECDSA is usually used with other curves. However, traditional |
2216 | ECDSA curves are problematic for a range of reasons described in | 2244 | ECDSA curves are problematic for a range of reasons described in |
2217 | the Curve25519 and EdDSA papers. Using EdDSA directly is also | 2245 | the Curve25519 and EdDSA papers. Using EdDSA directly is also |
2218 | not possible, as a hash function is used on the private key which | 2246 | not possible, as a hash function is used on the private key which |
2219 | destroys the linearity that the GNU Name System depends upon. | 2247 | destroys the linearity that the GNU Name System depends upon. |
2220 | We are not aware of anyone suggesting that using Curve25519 instead | 2248 | We are not aware of anyone suggesting that using Ed25519 instead |
2221 | of another common curve of similar size would lower the security of | 2249 | of another common curve of similar size would lower the security of |
2222 | ECDSA. GNS uses 256-bit curves because that way the encoded (public) | 2250 | ECDSA. GNS uses 256-bit curves because that way the encoded (public) |
2223 | keys fit into a single DNS label, which is good for usability. | 2251 | keys fit into a single DNS label, which is good for usability. |
@@ -2225,7 +2253,7 @@ NICK: john (Supplemental) | |||
2225 | <t> | 2253 | <t> |
2226 | In order to ensure ciphertext indistinguishability, care must be | 2254 | In order to ensure ciphertext indistinguishability, care must be |
2227 | taken with respect to the initialization vector in the counter | 2255 | taken with respect to the initialization vector in the counter |
2228 | block. In our design, the IV is always the expiration time of the | 2256 | block. In our design, the IV always includes the expiration time of the |
2229 | record block. | 2257 | record block. |
2230 | When applications store records with relative expiration times, | 2258 | When applications store records with relative expiration times, |
2231 | monotonicity is implicitly | 2259 | monotonicity is implicitly |
@@ -2284,8 +2312,8 @@ NICK: john (Supplemental) | |||
2284 | required to responsibly and diligently protect their cryptographic | 2312 | required to responsibly and diligently protect their cryptographic |
2285 | keys. | 2313 | keys. |
2286 | GNS supports offline signing of records. | 2314 | GNS supports offline signing of records. |
2287 | It does not support separate zone signing and key-signing keys | 2315 | <!-- It does not support separate zone signing and key-signing keys |
2288 | (as in <xref target="RFC6781" />) in order to provide usable security. | 2316 | (as in <xref target="RFC6781" />) in order to provide usable security. This is not useful for any implementer --> |
2289 | </t> | 2317 | </t> |
2290 | <t> | 2318 | <t> |
2291 | Similarly, users are required to manage their local start zone configuration. | 2319 | Similarly, users are required to manage their local start zone configuration. |
@@ -2353,7 +2381,7 @@ NICK: john (Supplemental) | |||
2353 | </t> | 2381 | </t> |
2354 | <ol> | 2382 | <ol> |
2355 | <li> | 2383 | <li> |
2356 | If revocation is used after a private key was compromised, | 2384 | If a revocation is published after a private key was compromised, |
2357 | allowing key replacement would be dangerous: if an | 2385 | allowing key replacement would be dangerous: if an |
2358 | adversary took over the private key, the adversary could then | 2386 | adversary took over the private key, the adversary could then |
2359 | broadcast a revocation with a key replacement. For the replacement, | 2387 | broadcast a revocation with a key replacement. For the replacement, |
@@ -2377,7 +2405,7 @@ NICK: john (Supplemental) | |||
2377 | <section anchor="privacy_labels" numbered="true" toc="default"> | 2405 | <section anchor="privacy_labels" numbered="true" toc="default"> |
2378 | <name>Label Guessing</name> | 2406 | <name>Label Guessing</name> |
2379 | <t> | 2407 | <t> |
2380 | Record blocks are published encrypted using keys derived from the | 2408 | Record blocks are published in encrypted form using keys derived from the |
2381 | zone key and record label. Zone administrators should | 2409 | zone key and record label. Zone administrators should |
2382 | carefully consider if the label and zone key may be public or if | 2410 | carefully consider if the label and zone key may be public or if |
2383 | those should be used and considered as a shared secret. | 2411 | those should be used and considered as a shared secret. |
@@ -2404,8 +2432,8 @@ NICK: john (Supplemental) | |||
2404 | <name>GANA Considerations</name> | 2432 | <name>GANA Considerations</name> |
2405 | <t> | 2433 | <t> |
2406 | GANA <xref target="GANA" /> | 2434 | GANA <xref target="GANA" /> |
2407 | is requested to create an "GNU Name System Record Types" registry. | 2435 | manages the "GNU Name System Record Types" registry. |
2408 | The registry shall record for each entry: | 2436 | Each entry has the following format: |
2409 | </t> | 2437 | </t> |
2410 | <ul> | 2438 | <ul> |
2411 | <li>Name: The name of the record type (case-insensitive ASCII | 2439 | <li>Name: The name of the record type (case-insensitive ASCII |
@@ -2420,12 +2448,15 @@ NICK: john (Supplemental) | |||
2420 | (such as an RFC)</li> | 2448 | (such as an RFC)</li> |
2421 | </ul> | 2449 | </ul> |
2422 | <t> | 2450 | <t> |
2423 | The registration policy for this sub-registry is "First Come First | 2451 | The registration policy for this registry is "First Come First |
2424 | Served". This policy is modeled on that described in <xref target="RFC8126"/>, | 2452 | Served". This policy is modeled on that described in <xref target="RFC8126"/>, |
2425 | but describes the actions taken by GANA. | 2453 | and describes the actions taken by GANA: |
2426 | </t> | 2454 | </t> |
2427 | <t> | 2455 | <t> |
2428 | Adding records is possible after expert review, using a | 2456 | <!-- FIXME: Unclear who are the experts how are they selected and |
2457 | by whom? GNUnet e.V. Politbüro? The DAO? | ||
2458 | Unreserved/Reserved for private use record type range? --> | ||
2459 | Adding new records is possible after expert review, using a | ||
2429 | first-come-first-served policy for unique name allocation. | 2460 | first-come-first-served policy for unique name allocation. |
2430 | Experts are responsible to ensure that the chosen "Name" is | 2461 | Experts are responsible to ensure that the chosen "Name" is |
2431 | appropriate for the record type. | 2462 | appropriate for the record type. |