Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <draft-schanzen-gns-28> for your review
"Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org> Tue, 24 October 2023 05:04 UTC
Return-Path: <rfc-ise@rfc-editor.org>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E49C15199D; Mon, 23 Oct 2023 22:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level:
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PmWKz3bhTAQ; Mon, 23 Oct 2023 22:04:50 -0700 (PDT)
Received: from [192.168.0.99] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id A7D11C151081; Mon, 23 Oct 2023 22:04:47 -0700 (PDT)
Message-ID: <d00069aa-8a84-452b-8cd8-583a8ac29431@rfc-editor.org>
Date: Tue, 24 Oct 2023 07:04:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: rfc-editor@rfc-editor.org, martin.schanzenbach@aisec.fraunhofer.de, christian.grothoff@bfh.ch, fix@gnunet.org
Cc: auth48archive@rfc-editor.org
References: <20231023164059.B16691963225@rfcpa.amsl.com>
From: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
In-Reply-To: <20231023164059.B16691963225@rfcpa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/BBrKeKifRoyW0FBWbvEtrKFE4lM>
Subject: Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <draft-schanzen-gns-28> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2023 05:04:54 -0000
Thank you, RFC Editor. Authors: please promptly address each point made. Eliot On 23.10.2023 18:40, rfc-editor@rfc-editor.org wrote: > Authors and Eliot, > > * Eliot, as ISE, please reply regarding #29. > > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. > > 1) <!-- [rfced] Please note that because this XML file was submitted in > "prepped" format, we created an "unprepped" file so that we could > edit the document properly. This does not impact the document's > text but resulted in many changes to the XML. --> > > > 2) <!-- [rfced] Datatracker "idnits" output for the original approved > document included the following warning. Although an author recently > referred to the lines indicated in this warning as "false positives", > please let us know if any changes are needed as related to this > warning: > > == There are 6 instances of lines with non-RFC2606-compliant FQDNs in > the document. --> > > > 3) <!-- [rfced] Abstract and subsequent: To what does "including" refer > in the following sentences? If our suggestions are incorrect, please > clarify the text in each sentence. > > Original: > It is published here to inform readers about the > function of GNS, guide future GNS implementations, and ensure > interoperability among implementations including with the pre- > existing GNUnet implementation. > ... > When names are resolved, signatures on resource > records including delegations are verified by the recursive > resolver. > ... > In the remainder of this document, the "implementer" refers to the > developer building a GNS implementation including the resolver, zone > master, and supporting configuration such as start zones (see > Section 7.1). > ... > The encoding and decoding symbols for Base32GNS including > this modification are defined in Figure 30. > ... > It > defines the context in which the signature is created so that it > cannot be reused in other parts of the protocol including possible > future extensions. > ... > It > defines the context in which the signature is created so that it > cannot be reused in other parts of the protocol including possible > future extensions. > > Suggested: > It is published here to inform readers about the > function of the GNS, guide future GNS implementations, and ensure > interoperability among implementations (for example, pre- > existing GNUnet implementations). > ... > When names are resolved, signatures on resource > records, including delegations, are verified by the recursive > resolver. > ... > In the remainder of this document, the "implementer" refers to the > developer who builds a GNS implementation that includes the > resolver, zone master, and supporting configuration such as start > zones (see Section 7.1). > ... > The encoding and decoding symbols for Base32GNS, including > this variation, are defined in Table 4 (Appendix C). > ... > It > defines the context in which the signature is created so that it > cannot be reused in other parts of the protocol that might include > possible future extensions. > ... > It > defines the context in which the signature is created so that it > cannot be reused in other parts of the protocol that might include > possible future extensions. --> > > > 4) <!-- [rfced] Please review each artwork element in the XML file. > Should any artwork element be tagged as sourcecode? For example, > should the "GET / HTTP/1.1" entries in Appendix A.3 be sourcecode > with type="http-message", and should the test-vector entries in > Appendix D be sourcecode with type="test-vectors"? > > Please see > <https://www.rfc-editor.org/materials/sourcecode-types.txt>; if the > current list of preferred values for "type" does not contain an > applicable type, please let us know. Also, it is acceptable to leave > the "type" attribute unset. --> > > > 5) <!-- [rfced] The following author comments, as found in the original > XML file, appear to be pending. Is any action required for the > following? > > FIXME: Is this really really necessary? Really? > FIXME: add non-normative reference to Tor / Tor hidden services here? > FIXME replace with RFC > Check if we want to use RFC8032 instead of paper ed25519 --> > > > 6) <!-- [rfced] Section 1: As there can only be one "first", we changed > "A first" to "One of the first" here. If this is incorrect, please > provide clarifying text. > > Original: > A first academic description of the > cryptographic ideas behind GNS can be found in [GNS]. > > Currently: > One of the first academic > descriptions of the cryptographic ideas behind GNS can be found in > [GNS]. --> > > > 7) <!-- [rfced] Section 2: To what does "in examples which is" refer? > Should it say "in examples that are" or something else? Please > clarify. > > Original: > In order to avoid misinterpretation of example > domains with (reserved) DNS domains this draft uses the suffix > ".gns.alt" in examples which is also registered in the GANA ".alt > Subdomains" registry [GANA] (see also [I-D.ietf-dnsop-alt-tld]). --> > > > 8) <!-- [rfced] Section 2: As it appears that "which" in this text > refers to the zTLD (per Sections 4 and 4.1), we updated this item > accordingly. If this is incorrect, please provide clarifying text. > > Original: > Zone Top-Level Domain A GNS Zone Top-Level Domain (zTLD) is a > sequence of GNS labels at the end of a GNS name which encodes a > zone type and zone key of a zone (see Section 4.1). > > Currently: > Zone Top-Level Domain (zTLD): A GNS zTLD is a sequence of GNS labels > at the end of a GNS name. The zTLD encodes a zone type and zone > key of a zone (see Section 4.1). --> > > > 9) <!-- [rfced] Section 4.1: As it appears that "this table" refers to > what is now Table 4 in Appendix C, we updated these two sentences > accordingly. If these updates are not correct, please clarify > "this table". > > Original: > The encoding and decoding symbols for Base32GNS including > this modification are defined in Figure 30. The functions for > encoding and decoding based on this table are called Base32GNS-Encode > and Base32GNS-Decode, respectively. > > Currently: > The > encoding and decoding symbols for Base32GNS including this > modification are defined in Table 4 (Appendix C). The functions for > encoding and decoding based on Table 4 are called Base32GNS-Encode > and Base32GNS-Decode, respectively. --> > > > 10) <!-- [rfced] Figures 3 through 7 and 20 through 22: Should the use > of vertical lines ("|") versus slashes "/") be made consistent where > the continuation of fields is indicated? If so, how? > > A few examples (double dashes removed to avoid confusion with XML > comments): > > | ZONE TYPE | ZONE KEY / > +- - -+- - -+- - -+- - -+ / > / / > / / > > ... > > | ZONE TYPE | ZONE KEY | > +- - -+- - -+- - -+- - -+ | > / / > / / > > ... > > | BDATA / > / / > / | > > ... > > | BDATA | > / / > / / --> > > > 11) <!-- [rfced] Section 4.2: We found "a number Z different PoWs" > difficult to follow. We updated the text per the definition of "Z" > that appears a few lines later. Please let us know any objections. > > Original: > In order to > reduce the variance in time it takes to calculate the PoW, a valid > GNS revocation requires that a number Z different PoWs must be found > that on average have D leading zeroes. > > Currently: > In order to > reduce the variance in time it takes to calculate the PoW, a valid > GNS revocation requires that a number of different PoWs (Z, as > defined below) must be found that on average have D leading zeroes. --> > > > 12) <!-- [rfced] Section 4.2: Does "time stamp and public key fields" > mean "TIMESTAMP and PUBLIC KEY fields", even though we only see > "PUBLIC KEY" mentioned in Sections 5.1.1 and 5.1.2? > > Original: > The signature over the public key covers a 32-bit header prefixed to > the time stamp and public key fields. --> > > > 13) <!-- [rfced] Sections 4.2 and subsequent: Please note that we > updated some of the GANA registry names to match those found on > [GANA]. Please review, and let us know any objections. > > Examples from original: > .alt subdomains (Section 10.2) > GNUnet Signature Purpose (Sections 4.2, 6.3, and 10) > GANA "Overlay Protocols" registry (Section 5.3.3) > GNU Name System Record Types (Section 10.1) > GANA Resource Record (Figure 25 in Section 10.1) > > Currently: > .alt Subdomains (also per Section 10.2, and per [GANA]) > GNUnet Signature Purposes > GANA "GNUnet Overlay Protocols" registry > GNS Record Types > GANA GNS Record Types (title of what is now Table 2) --> > > > 14) <!-- [rfced] Section 4.2: As it appears that "evict then from" > should be "evict them from", we updated accordingly. If this is > incorrect, please clarify "evict then from". > > Original (the previous sentence is included for context): > Verified revocations MUST be stored locally. The implementation MAY > discard stale revocations and evict then from the local store at any > time. > > Currently: > The implementation MAY > discard stale revocations and evict them from the local store at any > time. --> > > > 15) <!-- [rfced] Section 5: Please confirm that "16-bit bit field" (and > not "16-bit field") is correct. > > Original: > FLAGS is a 16-bit bit field indicating special properties of the > resource record. > > Possibly: > FLAGS: 16 bits. A bit field indicating special properties of the > resource record. --> > > > 16) <!-- [rfced] Section 5: xml2rfc v3 permits superscripting. Would > you like to apply superscripting to numbers where the caret ("^") is > used (e.g., 2^16, 2^255)? The superscripts would appear in the HTML > and PDF output files, but the textfile would still show the caret. > For an example, please see the last paragraph in Section 2.4.2 of > RFC 9426 (https://www.rfc-editor.org/rfc/rfc9426.html). > > If yes, please also let us know if anything else might need to be > superscripted or subscripted. --> > > > 17) <!-- [rfced] Sections 5.1.1 and 5.1.2: "using an HKDF using" reads > oddly. Does it mean "using an HKDF that uses", "using an HKDF and > using" (i.e., the key material is retrieved by using an HKDF as well > as the string "key-derivation"), or something else? If this needs to > be clarified, please provide updated text. > > Original: > PRK_h is key material retrieved using an HKDF using the string "key- > derivation" as salt and the zone key as initial keying material. > ... > PRK_h is key material retrieved using an HKDF using the string "key- > derivation" as salt and the zone key as initial keying material. > > Possibly: > PRK_h is key material retrieved using an HKDF that uses the string > "key-derivation" as the salt and the zone key as the initial keying > material. > ... > PRK_h is key material retrieved using an HKDF that uses the string > "key-derivation" as the salt and the zone key as the initial keying > material. --> > > > 18) <!-- [rfced] Section 5.1.1: For ease of the reader, we defined "IV" > as "Initialization Vector" here, per the title of Figure 12. Please > let us know any concerns. > > Original: > The key K and counter IV are derived from the record label and the > zone key zk using an HKDF as defined in [RFC5869]. > > Currently: > The key K and counter IV (Initialization Vector) are derived from the > record label and the zone key zk, using an HKDF as defined in > [RFC5869]. --> > > > 19) <!-- [rfced] Section 5.1.2: This sentence is very difficult to > parse; it is not clear what represents the KeyGen() function. Should > parentheses be added, per the definition of KeyGen() provided in > Section 5.1.1? > > Original: > KeyGen() The generation of the private key d and the associated > public key zk := a*G where G is the group generator of the > elliptic curve and a is an integer derived from d using the > SHA-512 hash function as defined in Section 5.1.5 of [RFC8032] > represents the KeyGen() function. > > Definition in Section 5.1.1 (for comparison purposes): > KeyGen() The generation of the private scalar d and the curve point > zk := d*G (where G is the group generator of the elliptic curve) > as defined in Section 2.2. of [RFC6979] represents the KeyGen() > function. --> > > > 20) <!-- [rfced] Section 5.1.2: For ease of the reader, may we clarify > this text as suggested? > > Original: > The calculation > of a is defined in Section 5.1.5 of [RFC8032]. > > Suggested: > As noted above for KeyGen(), a is calculated from d using the > SHA-512 hash function as defined in Section 5.1.5 of [RFC8032]. --> > > > 21) <!-- [rfced] Section 5.1.2: > a) Because it appears that using d' (as opposed to d' itself) is not > compliant with [RFC8032], we updated this sentence accordingly. If > this is not correct, please provide clarifying text. > > Original: > Signatures for EDKEY zones use a derived private scalar d' which is > not compliant with [RFC8032]. > > Currently: > Signatures for EDKEY zones use a derived private scalar d'; this is > not compliant with [RFC8032]. > > b) We found "key to" confusing in this context. Should "key to" be > "key for" here? > > Original: > As the corresponding private key to > the derived private scalar is not known, it is not possible to > deterministically derive the signature part R according to [RFC8032]. > > Perhaps: > As the corresponding private key for > the derived private scalar is not known, it is not possible to > deterministically derive the signature part R according to [RFC8032]. > > Or possibly: > As the private key that corresponds to > the derived private scalar is not known, it is not possible to > deterministically derive the signature part R according to [RFC8032]. --> > > > 22) <!-- [rfced] Section 5.1.2: We could not find any mention of > "Poly1305", "Poly", or "1305" in [XSalsa20]. Will this sentence be > clear to readers? > > Original: > The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in > [XSalsa20] (XSalsa20-Poly1305): > > Possibly: > The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in > [XSalsa20] and use the XSalsa20-Poly1305 encryption function: --> > > > 23) <!-- [rfced] Sections 5.2.1 and subsequent: Per more common usage in > published RFCs, we changed "0-terminated" to "zero terminated", as this > term is not used as a modifier. Please let us know any objections. > > Original: > The string is UTF-8 encoded and 0-terminated. > ... > The value is UTF-8 encoded > and 0-terminated. > ... > The value is UTF-8 encoded and 0-terminated. > ... > A UTF-8 string (which is not 0-terminated) > representing the legacy hostname. > ... > A UTF-8 string (which is not 0-terminated) representing the > preferred label of the zone. > > Currently: > The string is UTF-8 encoded and zero terminated. > ... > The value is UTF-8 encoded > and zero terminated. > ... > The value is UTF-8 encoded and zero terminated. > ... > A UTF-8 string (which is not zero terminated) > representing the legacy hostname. > ... > A UTF-8 string (which is not zero terminated) representing > the preferred label of the zone. --> > > > 24) <!-- [rfced] Section 6: Do "176 byte blocks" and "1024 byte blocks" > refer to blocks that are (at least) 176 bytes or 1024 bytes in size, > or is "byte blocks" a proper term (as in some number of byte blocks)? > > Original: > To be useful, the API MUST permit > storing at least 176 byte blocks to be able to support the defined > zone delegation record encodings, and SHOULD allow at least 1024 byte > blocks. > > Possibly: > To be useful, and to be able to support the defined zone delegation > record encodings, the API MUST permit storing blocks of size 176 bytes > or more and SHOULD allow blocks of size 1024 bytes or more. --> > > > 25) <!-- [rfced] Section 6.3: Does "is considered" refer to the maximum > expiration time only (in which case "is" is correct) or the maximum > expiration time and also the expiration times of the non-shadow > records (in which case "is" should be "are")? > > Original: > If the RDATA includes shadow > records, then the maximum expiration time of all shadow records > with matching type and the expiration times of the non-shadow > records is considered. --> > > > 26) <!-- [rfced] Section 7.3.2: We had trouble following the "and" > relationships in this sentence. We updated as follows. If this is > incorrect, please clarify the text. > > Original: > When a resolver encounters one or more GNS2DNS records and the > remaining name is empty and the desired record type is GNS2DNS, the > GNS2DNS records are returned. > > Currently: > When a resolver encounters one or more GNS2DNS records, the > remaining name is empty, and the desired record type is GNS2DNS, the > GNS2DNS records are returned. --> > > > 27) <!-- [rfced] Section 7.3.2: We changed "error is SHOULD be returned" > to "error SHOULD be returned" here. Please let us know if the text > should be "error is returned" instead. > > Original: > If > different DNS names are present the resolution fails and an > appropriate error is SHOULD be returned to the application. > > Currently: > If > different DNS names are present, the resolution fails and an > appropriate error SHOULD be returned to the application. --> > > > 28) <!-- [rfced] Section 7.3.4: This paragraph is difficult to parse. > For example, the last sentence is a fragment, and it isn't clear > under what circumstances the delegation record is returned. If the > suggested text is not correct, please clarify. > > Original: > If the remainder of the name to resolve is empty and a record set was > received containing only a single delegation record, the recursion is > continued with the record value as authoritative zone and the apex > label "@" as remaining name. Except in the case where the desired > record type as specified by the application is equal to the ztype, in > which case the delegation record is returned. > > Suggested: > If the remainder of the name to resolve is empty and a record set was > received containing only a single delegation record, the recursion is > continued with the record value as the authoritative zone and the > apex label "@" as the remaining name. The exception is the case > where the desired record type as specified by the application is > equal to the ztype, in which case the delegation record is returned. --> > > > 29) <!--[rfced] Section 9: [ISE] Please confirm that it is intentional > to title this section "Security and Privacy Considerations" > rather than "Security Considerations" as described in RFC 3552. > > Past RFCs have rarely used this title; specifically: > - RFC 9223 used it and had subsections to divide them. > - RFC 7989 used it (and did not have subsections). > --> > > > 30) <!-- [rfced] Section 9.1: Does "considered just like" here mean > "treated just like", "also considered to be just like", or something > else? Please clarify. > > Original: > Private records are > considered just like regular records when resolving labels in local > zones, but their data is completely unavailable to non-local users. --> > > > 31) <!-- [rfced] Section 9.3: In the first sentence, [ed25519] appears > to be one paper. Should RFC 7748 also be cited here as the other > paper? > > In the second sentence, does the hash function or the key destroy the > linearity that the key blinding in GNS depends upon? > > If the suggested text is not correct, please provide clarifying text. > > Original: > However, > standardized ECDSA curves are problematic for a range of reasons > described in the Curve25519 and EdDSA papers [ed25519]. Using EdDSA > directly is also not possible, as a hash function is used on the > private key which destroys the linearity that the key blinding in GNS > depends upon. > > Suggested (guessing the hash function and including RFC 7748): > However, > standardized ECDSA curves are problematic for a range of reasons, as > described in the Curve25519 and EdDSA papers [RFC7748] [ed25519]. > Using EdDSA directly is also not possible, as a hash function is > used on the private key and will destroy the linearity that the key > blinding in GNS depends upon. --> > > > 32) <!-- [rfced] Section 9.5: Because it appears that "or names" should > be "of names" here, we updated accordingly. Please let us know if > this is incorrect. > > Original: > In order to ensure integrity and availability or > names, users must ensure that their local start zone information is > not compromised or outdated. > > Currently: > In order to ensure the integrity and availability of > names, users must ensure that their local start zone information is > not compromised or outdated. --> > > > 33) <!-- [rfced] Section 9.5: Does "provided" only refer to the > processing, or does it also refer to the initial start zone (in > which case "is" should be "are")? > > Original: > It can be expected that the processing > of zone revocations and an initial start zone is provided with a GNS > implementation ("drop shipping"). --> > > > 34) <!-- [rfced] Section 9.10: As it appears that "taking into account" > applies to the applications and not some other method, we updated > this sentence accordingly. If this is incorrect, please provide > clarifying text. > > Original: > In order to prevent disclosure of queried GNS names it is RECOMMENDED > that GNS-aware applications try to resolve a given name in GNS before > any other method taking into account potential suffix-to-zone > mappings and zTLDs. > > Currently: > In order to prevent disclosure of queried GNS names, it is > RECOMMENDED that GNS-aware applications try to resolve a given name > in GNS before any other method, taking into account potential suffix- > to-zone mappings and zTLDs. --> > > > 35) <!-- [rfced] Section 9.10: As it appears that "It" in this sentence > refers to the NSS and not to a resolution process, we updated > accordingly, in line with text in the third paragraph of > Appendix A.4. If this is incorrect, please provide clarifying text. > > Original (the previous sentence is included for context): > Mechanisms such as the Name Service Switch (NSS) of Unix-like > operating systems are an example of how such a resolution process can > be implemented and used. It allows system administrators to > configure host name resolution precedence and is integrated with the > system resolver implementation. > > Currently: > The NSS allows system administrators to > configure hostname resolution precedence and is integrated with the > system resolver implementation. --> > > > 36) <!-- [rfced] Section 10: The title of this table seems to indicate > that the requested assignments have not yet been made. Should > "Requested" be "Assigned", as suggested below? > > Original: > Figure 24: Requested Changes in the GANA GNUnet Signature Purpose > Registry. > > Perhaps: > Table 1: Assigned Changes in the GANA GNUnet Signature Purposes > Registry > > Or possibly: > Table 1: The GANA GNUnet Signature Purposes Registry --> > > > 37) <!-- [rfced] Sections 10.1 and 10.2: Which paragraph or paragraphs > are referenced by these "by GANA:" sentences? We ask because of the > use of the colon (":"); it appears that one or more of the paragraphs > after the colon should appear as a list (i.e., should be > "bullet items"). > > Alternatively, should the colons be periods? > > Original: > The registration policy for this registry is "First Come First > Served". This policy is modeled on that described in [RFC8126], and > describes the actions taken by GANA: > > Adding new entries is possible after review by any authorized GANA > contributor, using a first-come-first-served policy for unique name > allocation. Reviewers are responsible to ensure that the chosen > "Name" is appropriate for the record type. The registry will define > a unique number for the entry. > > Authorized GANA contributors for review of new entries are reachable > at gns-registry@gnunet.org. > > Any request MUST contain a unique name and a point of contact. The > contact information MAY be added to the registry given the consent of > the requester. The request MAY optionally also contain relevant > references as well as a descriptive comment as defined above. > > GANA has assigned numbers for the record types defined in this > specification in the "GNU Name System Record Types" registry as > listed in Figure 25. > ... > The registration policy for this registry is "First Come First > Served". This policy is modeled on that described in [RFC8126], and > describes the actions taken by GANA: > > Adding new entries is possible after review by any authorized GANA > contributor, using a first-come-first-served policy for unique > subdomain allocation. Reviewers are responsible to ensure that the > chosen "Subdomain" is appropriate for the purpose. > > Authorized GANA contributors for review of new entries are reachable > at alt-registry@gnunet.org. > > Any request MUST contain a unique subdomain and a point of contact. > The contact information MAY be added to the registry given the > consent of the requester. The request MAY optionally also contain > relevant references as well as a descriptive comment as defined > above. > > GANA has assigned the subdomain defined in this specification in the > ".alt subdomains" registry as listed in Figure 26. > > Perhaps (Section 10.1; assuming that the next three paragraphs, and > not the "GANA has assigned" paragraph, should be in list form): > This policy is modeled on that described in [RFC8126] and > describes the actions taken by GANA: > > * Adding new entries is possible after review by any authorized > GANA contributor, using a first-come-first-served policy for > unique name allocation. Reviewers are responsible for ensuring > that the chosen "Name" is appropriate for the record type. The > registry will define a unique number for the entry. > > * Authorized GANA contributors for review of new entries are > reachable at gns-registry@gnunet.org. > > * Any request MUST contain a unique name and a point of contact. > The contact information MAY be added to the registry, with the > consent of the requester. The request MAY optionally also > contain relevant references as well as a descriptive comment, as > defined above. > > GANA has assigned numbers for the record types defined in this > specification in the "GNS Record Types" registry as listed in > Table 2. --> > > > 38) <!-- [rfced] Section 10.1: We see a discrepancy between this > document and [GANA] for the "BOX" entry (number 65541). It appears > that all other entries match. Should the listings be made > consistent between this document and [GANA]? If so, how? > > "Comment" entry for this document: Boxed records > "Comment" entry in the GANA "GNS Record Types" registry: Box record > --> > > > 39) <!-- [rfced] Section 10.2: Should "Comment" be "Description" in > these entries and should "Subdomain" be "Label" here, per [GANA] > (specifically https://gana.gnunet.org/dot-alt/dot_alt.html)? > > We also see "a first-come-first-served policy for unique subdomain > allocation" in the text in this section, so it's not clear whether > "Subdomain" or "Label" might be preferred for this document and > [GANA] (if they should indeed match). > > Original: > * Label: The label of the subdomain (in DNS LDH format as defined in > Section 2.3.1 of [RFC5890]). > > * Comment: Optionally, a brief English text describing the purpose > of the subdomain (in UTF-8) > ... > Subdomain | Contact | References | Comment > --> > > > 40) <!--[rfced] Section 12: Is it intentional to keep the > "Implementation and Deployment Status" section, or would > you like it to be removed before publication? > > Regarding "Implementation Status" sections in general, RFC 7942 states: > "We recommend that the Implementation Status section should be > removed from Internet-Drafts before they are published as RFCs." > > That said, if you prefer to keep it, that's fine. > --> > > > 41) <!-- [rfced] Normative References: Please confirm that the URL > provided for [XSalsa20] is stable. > > Original: > [XSalsa20] Bernstein, D., "Extending the Salsa20 nonce", 2011, > <https://cr.yp.to/snuffle/xsalsa-20110204.pdf>. --> > > > 42) <!-- [rfced] [SDSI]: The provided URL yields a "Not Found" error. > We see that > <https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.1.html>, dated > October 1996, works, but is it stable? We have been advised that > ".edu" URLs are not always stable. > > Please advise regarding how to update this listing, noting that we > try to use "https://" instead of "http://" as much as possible. > > Original: > [SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed > Security Infrastructure", April 1996, > <http://people.csail.mit.edu/rivest/Sdsi10.ps>. --> > > > 43) <!-- [rfced] Informative References: Please confirm that the URL > provided for [Kademlia] is stable. > > Original: > [Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer > information system based on the xor metric.", 2002, > <http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf>. --> > > > 44) <!-- [rfced] [GNUnetGNS]: The title as provided in this document > doesn't appear on the provided page. May we change the title to > "gnunet.git - GNUnet core repository"? > > Original: > [GNUnetGNS] > GNUnet e.V., "The GNUnet GNS Implementation", > <https://git.gnunet.org/gnunet.git/tree/src/gns>. --> > > > 45) <!-- [rfced] [Ascension]: The title as provided in this document > doesn't appear on the provided page. May we change the title to > "ascension.git - DNS zones to GNS migrating using incremental zone > transfer (AXFR/IXFR)"? > > Original: > [Ascension] > GNUnet e.V., "The Ascension Implementation", > <https://git.gnunet.org/ascension.git>. --> > > > 46) <!-- [rfced] [GNUnet]: The title as provided in this document > doesn't appear on the provided page. Should the title be updated? > > Original: > [GNUnet] GNUnet e.V., "The GNUnet Project", <https://gnunet.org>. > > Perhaps: > [GNUnet] GNUnet e.V., "The GNUnet Project (Home Page)", > 2023, <https://gnunet.org>. --> > > > 47) <!-- [rfced] Appendix A.2: Does the colon after "configuration" mean > that only the first paragraph that follows it applies, or do both > subsequent paragraphs apply? In other words, it appears that one or > both of the subsequent paragraphs should be in list form (i.e., a > bullet list). Please advise. > > Alternatively, should the colon be a period? > > Original: > At > this point the user may delete or otherwise modify the > implementation's default configuration: > > Deletion of suffix-to-zone mappings may become necessary of the zone > owner referenced by the mapping has lost the trust of the user. For > example, this could be due to lax registration policies resulting in > phishing activities. Modification and addition of new mappings are > means to heal the namespace perforation which would occur in the case > of a deletion or to simply establish a strong direct trust > relationship. However, this requires the user's knowledge of the > respective zone keys. This information must be retrieved out of > band, as illustrated in Appendix A.1: A bank may send the user a > letter with a QR code which contains the GNS zone of the bank. The > user scans the QR code and adds a new suffix-to-name mapping using a > chosen local name for his bank. Other examples include scanning zone > information off the device of a friend, from a storefront, or an > advertisement. The level of trust in the respective zone is > contextual and likely varies from user to user. Trust in a zone > provided through a letter from a bank which may also include a credit > card is certainly different from a zone found on a random > advertisement in the streets. However, this trust is immediately > tangible to the user and can be reflected in the local naming as > well. > > User clients should facilitate the modification of the start zone > configuration, for example by providing a QR code reader or other > import mechanisms. Implementations are ideally implemented according > to best practices and addressing applicable points from Section 9. > Formalizing such best practices is out of scope of this > specification. --> > > > 48) <!-- [rfced] Appendix A.2: We changed "necessary of" to "necessary > if" here. If this is incorrect, please provide clarifying text. > > Original: > Deletion of suffix-to-zone mappings may become necessary of the zone > owner referenced by the mapping has lost the trust of the user. > > Currently: > Deletion of suffix-to-zone mappings may become necessary if the zone > owner referenced by the mapping has lost the trust of the user. --> > > > 49) <!-- [rfced] Appendix A.3: We could not determine what a second > query might be or whether it might be important to point it out. > Will this text be clear to readers? If not, please provide > clarifying text. > > Original: > In order to determine the canonical representation of the record with > a zTLD, at most two queries are required: First, it must be checked > whether "www.example.gns.alt" itself points to a zone delegation > record which would imply that the record set which was originally > resolved is published under the apex label. --> > > > 50) <!-- [rfced] Appendix D.2: Should the following entries be written > consistently (i.e., with or without "delegation", with or without the > number of (delegation) records)? > > Original: > *(1) PKEY zone with ASCII label and one delegation record* > *(2) PKEY zone with UTF-8 label and three records* > *(3) EDKEY zone with ASCII label and delegation record* > *(4) EDKEY zone with UTF-8 label and three records* > > Possibly (assuming that "delegation" also applies to UTF-8 labels): > *(1) PKEY zone with ASCII label and one delegation record* > *(2) PKEY zone with UTF-8 label and three delegation records* > *(3) EDKEY zone with ASCII label and one delegation record* > *(4) EDKEY zone with UTF-8 label and three delegation records* --> > > > 51) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide at > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, > and let us know if any changes are needed. > > For example, please consider whether the following should be updated: > master (zone master) (perhaps "zone administrator") > his (generally changed to "their") > man-in-the-middle (sometimes changed to "on-path attacker") --> > > > 52) <!-- [rfced] Please let us know if any changes are needed for the > following: > > a) The following terms were used inconsistently in this document. > We chose to use the latter forms. Please let us know any objections. > > encode and decode symbols (Appendix C) / encoding and decoding symbols > > internet services / Internet services > > legacy host name / legacy hostname* > > * We also changed "host name" to "hostname" where used generally, > per "hostname resolution" in Appendix A.4. Please let us know > any objections. > > zeros / zeroes > > b) The following terms/phrases appear to be used inconsistently in > this document. Please let us know which form is preferred. > > for the nonce / for the NONCE > > "Host"-header (noun) / "Host:" header (noun) > (We also see '"Host"-header field' in Appendix A.3.) > > Keygen() / KeyGen() > > records block / record block (e.g., "resource records block > (RRBLOCK)", "resource record block (RRBLOCK)") > > REDIRECT DATA ("REDIRECT DATA entry") / > REDIRECT data ("the REDIRECT data") > > redirect name / REDIRECT NAME > > Redirect record (first sentence of Section 5.2) / > REDIRECT record (We also see "redirection record" in running text > and "with redirect" in Appendix B.2.) > > Start Zone / start zone (e.g., "a Start Zone", "the start zone") > > c) We see that "zone key" is defined as "zk" but that "zkey" is also > used. Please confirm that this is as intended and will be clear to > readers (e.g., are "zk" and "zkey" the same thing or two different > things?). We have a similar question regarding the use of > "zone type" and "ztype"; do they both mean the same thing? > > d) Should "record data" be defined as "RDATA" at first use and > "RDATA" used thereafter? We ask because of "6.2. Plaintext Record > Data (RDATA)" and "Record data (RDATA) is the format ..." used a few > lines into Section 6.2. > > e) Please confirm that the usage of "boxed record" versus "BOX record" > is correct. > > f) Should the spacing of parameters in parentheses be made > consistent for the following? If so, how? > > For example: > > ZKDF(zk, label) > ZKDF(zk,label) > S-Encrypt(zk,label,expiration,plaintext) > Sign(d,message) > Verify(zk,message,signature) > PUT(key,block) > PUT(q, RRBLOCK) > ZKDF(zk0, "example") > > g) Should the following be consistently quoted in text or unquoted? > > For example: > the GNS name "www.example.gns" > the DNS name www.example.com > LEHO record (Section 5.3.1) containing "www.example.com" > a single REDIRECT record containing www2.+ --> > > > Thank you. > > RFC Editor/lb/ar > > > On Oct 23, 2023, rfc-editor@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2023/10/23 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info/). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-editor@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9498.xml > https://www.rfc-editor.org/authors/rfc9498.html > https://www.rfc-editor.org/authors/rfc9498.pdf > https://www.rfc-editor.org/authors/rfc9498.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9498-diff.html > https://www.rfc-editor.org/authors/rfc9498-rfcdiff.html (side by side) > > This alternate diff file shows the changes in the moved text: > https://www.rfc-editor.org/authors/rfc9498-alt-diff.html > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9498-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9498 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9498 (draft-schanzen-gns-28) > > Title : The GNU Name System > Author(s) : M. Schanzenbach, C. Grothoff, B. Fix >
- [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <draft-… rfc-editor
- [auth48] AUTH48: RFC-to-be 9498 <draft-schanzen-g… rfc-editor
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Schanzenbach, Martin
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Schanzenbach, Martin
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9498 <dr… Schanzenbach, Martin
- [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft-sch… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] Fwd: *[ISE] AUTH48: RFC-to-be 9498 <… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Bernd Fix
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] Fwd: *[ISE] AUTH48: RFC-to-be 9498 <… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Bernd Fix
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Bernd Fix
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Bernd Fix
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Christian Grothoff
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Schanzenbach, Martin
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Bernd Fix
- Re: [auth48] *[ISE] AUTH48: RFC-to-be 9498 <draft… Lynne Bartholomew