diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2022-05-05 16:26:10 +0200 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2022-05-05 16:26:10 +0200 |
commit | 8e684c59d2ba8cd839be2a0bbf21201aec3f910b (patch) | |
tree | c0a76ed5d4030eb41174cdbf06438513fd031721 | |
parent | d50b7a0448378f4f58c1c7fd4c6c3afc45ad872c (diff) | |
download | lsd0001-8e684c59d2ba8cd839be2a0bbf21201aec3f910b.tar.gz lsd0001-8e684c59d2ba8cd839be2a0bbf21201aec3f910b.zip |
more feedback integrated
-rw-r--r-- | draft-schanzen-gns.xml | 40 | ||||
-rw-r--r-- | rs_review_202204.txt | 28 |
2 files changed, 49 insertions, 19 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index e0b38de..50f71cd 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -14,6 +14,7 @@ | |||
14 | <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> | 14 | <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> |
15 | <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> | 15 | <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> |
16 | <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> | 16 | <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> |
17 | <!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"> | ||
17 | <!ENTITY RFC6234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml"> | 18 | <!ENTITY RFC6234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml"> |
18 | <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> | 19 | <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> |
19 | <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> | 20 | <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> |
@@ -450,8 +451,8 @@ | |||
450 | <section anchor="zones" numbered="true" toc="default"> | 451 | <section anchor="zones" numbered="true" toc="default"> |
451 | <name>Zones</name> | 452 | <name>Zones</name> |
452 | <t> | 453 | <t> |
453 | A zone master implementation <bcp14>SHOULD</bcp14> enable the user to | 454 | A zone master implementation <bcp14>SHOULD</bcp14> enable the zone |
454 | create and manage zones. | 455 | owners to create and manage zones. |
455 | If this functionality is not implemented, names can still be resolved | 456 | If this functionality is not implemented, names can still be resolved |
456 | if zone keys for the initial step in the name resolution are available | 457 | if zone keys for the initial step in the name resolution are available |
457 | (see <xref target="resolution"/>). | 458 | (see <xref target="resolution"/>). |
@@ -535,6 +536,8 @@ | |||
535 | document. | 536 | document. |
536 | All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation | 537 | All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation |
537 | record types in the GNU Name System Record Types registry (see <xref target="gana"/>). | 538 | record types in the GNU Name System Record Types registry (see <xref target="gana"/>). |
539 | When defining new record types the cryptographic security considerations | ||
540 | of this document apply, in particular <xref target="security_cryptography"/>. | ||
538 | </t> | 541 | </t> |
539 | <section anchor="zTLD" numbered="true" toc="default"> | 542 | <section anchor="zTLD" numbered="true" toc="default"> |
540 | <name>Zone Top-Level Domain</name> | 543 | <name>Zone Top-Level Domain</name> |
@@ -568,7 +571,10 @@ | |||
568 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 571 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
569 | zTLD := Base32GNS-Encode(ztype||zkey) | 572 | zTLD := Base32GNS-Encode(ztype||zkey) |
570 | ztype||zkey := Base32GNS-Decode(zTLD) | 573 | ztype||zkey := Base32GNS-Decode(zTLD) |
571 | ]]></artwork> | 574 | ]]></artwork> |
575 | <t> | ||
576 | where "||" is the concatenation operator. | ||
577 | </t> | ||
572 | <t> | 578 | <t> |
573 | The zTLD can be used as-is as a rightmost label in a GNS name. | 579 | The zTLD can be used as-is as a rightmost label in a GNS name. |
574 | If an application wants to ensure DNS compatibility of the name, | 580 | If an application wants to ensure DNS compatibility of the name, |
@@ -589,7 +595,7 @@ ztype||zkey := Base32GNS-Decode(zTLD) | |||
589 | <!-- FIXME: Is this really really necessary? Really? --> | 595 | <!-- FIXME: Is this really really necessary? Really? --> |
590 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 596 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
591 | zTLD[126..129].zTLD[63..125].zTLD[0..62] | 597 | zTLD[126..129].zTLD[63..125].zTLD[0..62] |
592 | ]]></artwork> | 598 | ]]></artwork> |
593 | </section> | 599 | </section> |
594 | <section anchor="revocation" numbered="true" toc="default"> | 600 | <section anchor="revocation" numbered="true" toc="default"> |
595 | <name>Zone Revocation</name> | 601 | <name>Zone Revocation</name> |
@@ -1016,6 +1022,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62] | |||
1016 | There <bcp14>MAY</bcp14> be inactive records of the same type which have | 1022 | There <bcp14>MAY</bcp14> be inactive records of the same type which have |
1017 | the SHADOW flag set in order to facilitate smooth key rollovers. | 1023 | the SHADOW flag set in order to facilitate smooth key rollovers. |
1018 | </t> | 1024 | </t> |
1025 | <t> | ||
1026 | In the following, "||" is the concatenation operator of two byte strings. | ||
1027 | The algorithm specification uses character strings such as GNS labels or | ||
1028 | constant values. | ||
1029 | When used in concatenations or as input to functions the | ||
1030 | null-terminator of the character strings <bcp14>MUST NOT</bcp14> be | ||
1031 | included. | ||
1032 | </t> | ||
1019 | <section anchor="gnsrecords_pkey" numbered="true" toc="default"> | 1033 | <section anchor="gnsrecords_pkey" numbered="true" toc="default"> |
1020 | <name>PKEY</name> | 1034 | <name>PKEY</name> |
1021 | <t> | 1035 | <t> |
@@ -1557,9 +1571,11 @@ S-Decrypt(zk,label,expiration,ciphertext): | |||
1557 | DNS name of the service to be transmitted over the transport protocol. | 1571 | DNS name of the service to be transmitted over the transport protocol. |
1558 | In GNS, legacy host name records provide applications the DNS name that | 1572 | In GNS, legacy host name records provide applications the DNS name that |
1559 | is required to establish a connection to such a service. | 1573 | is required to establish a connection to such a service. |
1560 | The most common use case is HTTP virtual hosting, where a DNS name must | 1574 | The most common use case is HTTP virtual hosting and TLS Server Name |
1561 | be supplied in the HTTP "Host"-header. | 1575 | Indication <xref target="RFC6066"/>, where a DNS name must |
1562 | Using a GNS name for the "Host"-header might not work as | 1576 | be supplied in the HTTP "Host"-header and the TLS handshake, |
1577 | respectively. | ||
1578 | Using a GNS name in those cases might not work as | ||
1563 | it might not be globally unique. Furthermore, even if uniqueness is | 1579 | it might not be globally unique. Furthermore, even if uniqueness is |
1564 | not an issue, the legacy service might not even be aware of GNS. | 1580 | not an issue, the legacy service might not even be aware of GNS. |
1565 | </t> | 1581 | </t> |
@@ -1688,7 +1704,7 @@ S-Decrypt(zk,label,expiration,ciphertext): | |||
1688 | </section> | 1704 | </section> |
1689 | </section> | 1705 | </section> |
1690 | <section anchor="publish" numbered="true" toc="default"> | 1706 | <section anchor="publish" numbered="true" toc="default"> |
1691 | <name>Record Storage</name> | 1707 | <name>Record Encoding</name> |
1692 | <t> | 1708 | <t> |
1693 | Any API which allows storing a value under a 512-bit key and retrieving | 1709 | Any API which allows storing a value under a 512-bit key and retrieving |
1694 | one or more values from the key can be used by an implementation for record storage. | 1710 | one or more values from the key can be used by an implementation for record storage. |
@@ -2451,6 +2467,12 @@ NICK: john (Supplemental) | |||
2451 | <section anchor="security_cryptography" numbered="true" toc="default"> | 2467 | <section anchor="security_cryptography" numbered="true" toc="default"> |
2452 | <name>Cryptography</name> | 2468 | <name>Cryptography</name> |
2453 | <t> | 2469 | <t> |
2470 | The following considerations provide background on the design choices | ||
2471 | of the ztypes specified in this document. | ||
2472 | When specifying new ztypes as per <xref target="zones"/>, the same | ||
2473 | considerations apply. | ||
2474 | </t> | ||
2475 | <t> | ||
2454 | GNS PKEY zone keys use ECDSA over Ed25519. | 2476 | GNS PKEY zone keys use ECDSA over Ed25519. |
2455 | This is an unconventional choice, | 2477 | This is an unconventional choice, |
2456 | as ECDSA is usually used with other curves. However, standardized | 2478 | as ECDSA is usually used with other curves. However, standardized |
@@ -2934,7 +2956,7 @@ Purpose | Name | References | Comment | |||
2934 | <references> | 2956 | <references> |
2935 | <name>Informative References</name> | 2957 | <name>Informative References</name> |
2936 | &RFC4033; | 2958 | &RFC4033; |
2937 | <!-- &RFC6781; --> | 2959 | &RFC6066; |
2938 | &RFC7363; | 2960 | &RFC7363; |
2939 | &RFC8324; | 2961 | &RFC8324; |
2940 | &RFC8806; | 2962 | &RFC8806; |
diff --git a/rs_review_202204.txt b/rs_review_202204.txt index 419dc0e..3b28856 100644 --- a/rs_review_202204.txt +++ b/rs_review_202204.txt | |||
@@ -33,8 +33,7 @@ Each definition might be more clear if the repetition of the term were omitted a | |||
33 | 33 | ||
34 | In the "Name" definition, do you mean "applications MAY *require* that ... "? | 34 | In the "Name" definition, do you mean "applications MAY *require* that ... "? |
35 | 35 | ||
36 | ===== I think we could also formulate it like that. But that would be a normative statement for the application | 36 | ===== I think we could also formulate it like that. But that would be a normative statement for the application as opposed to a normative statement what the GNS impl. should expect. => No change. |
37 | as opposed to a normative statement what the GNS impl. should expect. | ||
38 | 37 | ||
39 | Using "Zone type" as the term for cipher and encoding seemed strange to me, why not "Zone Representation" or something shorter? One or two examples before the terms, with text identifying the parts in the definition, would be helpful. | 38 | Using "Zone type" as the term for cipher and encoding seemed strange to me, why not "Zone Representation" or something shorter? One or two examples before the terms, with text identifying the parts in the definition, would be helpful. |
40 | 39 | ||
@@ -46,7 +45,7 @@ Sec 3, "cryptographically secured zones" is redundant, aren't all zones cryptogr | |||
46 | 45 | ||
47 | Last sentence of first paragraph repeats the definition we just read. | 46 | Last sentence of first paragraph repeats the definition we just read. |
48 | 47 | ||
49 | ===== I don't think so. | 48 | ===== Unable to find this issue in the text itself. |
50 | 49 | ||
51 | Second para "A zone can be populated by its owner with ..." A clarification that the distributed storage isn't required by the protocol would be useful. | 50 | Second para "A zone can be populated by its owner with ..." A clarification that the distributed storage isn't required by the protocol would be useful. |
52 | 51 | ||
@@ -54,21 +53,23 @@ Second para "A zone can be populated by its owner with ..." A clarification that | |||
54 | 53 | ||
55 | The text introducing figure 2 makes me think it's going to show all the flows for a recursive resolution, and it is rather a high-level view. | 54 | The text introducing figure 2 makes me think it's going to show all the flows for a recursive resolution, and it is rather a high-level view. |
56 | 55 | ||
57 | ===== That is what the figure description sais and I think this is enough for an "Overview". | 56 | ===== That is what the figure description sais and I think this is enough for an "Overview". |
58 | 57 | ||
59 | Sec 4, which user creates and manages zones? The Zone admin? The end-user? | 58 | Sec 4, which user creates and manages zones? The Zone admin? The end-user? |
60 | 59 | ||
61 | ==== TODO | 60 | ==== Zone owners. Clarified. |
62 | 61 | ||
63 | The forward ref to Section 5.1 should be before the list of algorithms in my opinion. | 62 | The forward ref to Section 5.1 should be before the list of algorithms in my opinion. |
64 | 63 | ||
65 | ==== TODO. After first review I disagree as it refers to the functions which are introduced above. | 64 | ==== After review I disagree as it refers to the functions which are introduced above that text. |
66 | 65 | ||
67 | Sec 4.1, maybe say "||" is the concatenation operator and that "[a..b]" is the semi-closed range from A to B-1 | 66 | Sec 4.1, maybe say "||" is the concatenation operator and that "[a..b]" is the semi-closed range from A to B-1 |
68 | 67 | ||
68 | ==== Clarified the use of the operators. | ||
69 | |||
69 | Sec 4.2, "strictly monotonically increasing order" I think monotonically is wrong. | 70 | Sec 4.2, "strictly monotonically increasing order" I think monotonically is wrong. |
70 | 71 | ||
71 | ====== I am 95% sure that monotonically is correct when we talk about a function. Not sure about order. | 72 | ====== I am 99% sure that monotonically is correct and the important part. |
72 | 73 | ||
73 | Sec 5, nice to block of IANA numbers for interop. Are timestamps in GNS always 64bit microsec since 1/1/1970? Maybe add a definition or something at the top? | 74 | Sec 5, nice to block of IANA numbers for interop. Are timestamps in GNS always 64bit microsec since 1/1/1970? Maybe add a definition or something at the top? |
74 | 75 | ||
@@ -82,18 +83,23 @@ Sec 5.1.1, the crypto heart starts to appear. ;) This all looks okay to me, and | |||
82 | 83 | ||
83 | Sec 5.1.2, "highest 32 bytes" maybe "top-most"? Nit. SignDerived is clever. Consider asking CFRG to review the crypto in Sec 5. | 84 | Sec 5.1.2, "highest 32 bytes" maybe "top-most"? Nit. SignDerived is clever. Consider asking CFRG to review the crypto in Sec 5. |
84 | 85 | ||
86 | ======= We could do that, but then again we had a review by djb already. | ||
87 | |||
85 | Sec 5.2.1+5.2.2, have you thought of allowing multiple REDIRECT records to achieve some kind of load-balancing or other? | 88 | Sec 5.2.1+5.2.2, have you thought of allowing multiple REDIRECT records to achieve some kind of load-balancing or other? |
86 | 89 | ||
87 | ======= Q: Maybe we want this? CNAME did not allow this, but it seems to be used in practice occasionally https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm#dns4-CHP-10-SECT-7.1 | 90 | ======= This is a CNAME-derivative. It seems that CNAMEs do not support this either: https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm#dns4-CHP-10-SECT-7.1 |
88 | 91 | ||
89 | Sec 5.3.1, I would think TLS SNI value is also common for LEHO data. | 92 | Sec 5.3.1, I would think TLS SNI value is also common for LEHO data. |
90 | 93 | ||
94 | ===== Added ref to RFC6066 SNI | ||
95 | |||
91 | Sec 5.3.3, not unlike the new SVCB RR type? | 96 | Sec 5.3.3, not unlike the new SVCB RR type? |
92 | 97 | ||
98 | ==== Yeah, bit is still draft status (?). | ||
99 | |||
93 | Sec 6, is this whole storage strictly necessary for interop? You could split it off into a separate document. There's not enough here to implement the storage. What happens to resolution if the GET() fails? I assume that's discussed. | 100 | Sec 6, is this whole storage strictly necessary for interop? You could split it off into a separate document. There's not enough here to implement the storage. What happens to resolution if the GET() fails? I assume that's discussed. |
94 | 101 | ||
95 | ======= FIXME: We may want to consider renaming Section 6 and/or move it into a subsection of Section 5 as we do not really define the storage here. | 102 | ======= Renamed section to "Record Encoding" in order to avoid storage confusion. |
96 | ======= Record Wire Format / Record Encoding | ||
97 | 103 | ||
98 | Sec 7, the application filters record sets. Oh, that is *VERY* interesting. And that picture is starting to look familiar. Third time? | 104 | Sec 7, the application filters record sets. Oh, that is *VERY* interesting. And that picture is starting to look familiar. Third time? |
99 | 105 | ||
@@ -101,6 +107,8 @@ Sec 7.1+7.2+7.3 very nice, very clear, I could implement this (modulo the storag | |||
101 | 107 | ||
102 | Sec 9.3 seems very important. Somewhere up near the front you should forward-link to it. And in the security considerations, backlink. | 108 | Sec 9.3 seems very important. Somewhere up near the front you should forward-link to it. And in the security considerations, backlink. |
103 | 109 | ||
110 | ===== Added. | ||
111 | |||
104 | Sec 9.4, it's difficult because it requires law enforcement, etc., to get the private key? Is that really so hard? https://xkcd.com/538/ | 112 | Sec 9.4, it's difficult because it requires law enforcement, etc., to get the private key? Is that really so hard? https://xkcd.com/538/ |
105 | 113 | ||
106 | ==== No, because of the user-centric design for delegations. TODO: Clarify again in text? | 114 | ==== No, because of the user-centric design for delegations. TODO: Clarify again in text? |