[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-generalized-notify-06: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-generalized-notify-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ -- COMMENT: -- Thank you to Peter E. Yee for the GENART Review. ** Section 6.2. The expert review should validate that the RRtype and Scheme do not conflict with any existing allocations. Is this the totality of the guidance for the expert reviewer, lack of duplication? Is more detail required given the size of the code point space? ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-compact-denial-of-existence-06: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-compact-denial-of-existence-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/ -- COMMENT: -- Thank you to Elwyn Davies for the GENART review. ** Section 10. Be more precise with the registry names (i.e., using their actual names) OLD Allocate a new DNS Resource Record type code for NXNAME in the DNS parameters registry, from the meta type range. NEW Allocate a new DNS Resource Record type code for NXNAME from the "Resource Record (RR) TYPEs" registry in the "DNS parameters" registry group, from the meta type range. OLD Allocate the "Compact Answers OK" flag in the EDNS header, as described in Section 5.1. NEW Allocate the "Compact Answers OK" flag in the "EDNS Header Flags (16 bits) registry in the "Domain Name System (DNS) Parameters" registry group. Set the Flag field to "CO". OLD Allocate a code point for the "Invalid Query Type" Extended DNS Error in the DNS parameters registry, as described in Section 3.5. NEW Allocate a code point for the "Invalid Query Type" in the "Extended DNS Error Codes" registry in the "Domain Name System (DNS) Parameters" registry group, as described in Section 3.5. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-zoneversion-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/ -- COMMENT: -- idnits reports: ** The abstract seems to contain references ([RFC5001]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-qdcount-is-one-03: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-qdcount-is-one-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ -- COMMENT: -- ** idnits says == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. ** Section 4. Firewalls that process DNS messages in order to eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic and return a FORMERR response as described above. Such firewalls MUST NOT treat messages with OPCODE = 0 and QDCOUNT = 0 as malformed. See Section 4 of [RFC8906] for further guidance. (Editorial) Should the term “firewall” be generalized to “middle box” (or something similar)? I ask because I’m wondering if DNS proxies, UTMs, or IPSs should also follow this advice? ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Roman Danyliw's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ -- COMMENT: -- Thank you to Peter Yee for the GENART review. ** Section 6. Editorial. The level of rigor in Section 4.2 is needed to prevent publication of a half-baked DS RRset Is “half-baked DS RRset” a term-of-art? To improve readability, I recommend not using an idiomatic expression. ** Section 7. Editorial. Per the reference to [draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like “[This RFC]” and subsequent comment of that string being replaced by the RFC Editor. ** idnits reports: ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ -- COMMENT: -- Thank you to Donald Eastlake for his SECDIR review. Please review his proposed text on including clarifying language around the applicability of TSIG. I support Martin Duke and Rob Wilton’s DISCUSS positions. ** Section 7.2 This would indicate prior reliance upon IP fragmentation, which is universally considered to be harmful to both the performance and stability of applications, endpoints, and gateways. Is there a reference that can be cited to substantiate this “universal” position? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-glue-is-not-optional-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-glue-is-not-optional-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ -- COMMENT: -- ** Consider if RFC2119 keywords are appropriate in the abstract ** Section 2.4. Machine produced tool output is provided in this section (from dig). Please formally cite what generated it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
Hi Warren! Thanks for the explanations to my feedback. From: Warren Kumari Sent: Wednesday, April 26, 2023 11:49 AM To: Roman Danyliw Cc: The IESG ; draft-ietf-dnsop-alt-...@ietf.org; dnsop-cha...@ietf.org; dnsop@ietf.org; suzworldw...@gmail.com Subject: Re: Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT) On Tue, Apr 25, 2023 at 4:54 PM, Roman Danyliw mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ -- COMMENT: -- Thank you to Linda Dunbar for the SECDIR review. ** Section 2. Currently deployed projects and protocols that are using pseudo-TLDs are recommended to move under the .alt pseudo-TLD, but this is not a requirement. I don’t understand the basis of this recommendation. Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance. Why is there an expectation that this document can change behavior? It's not really an expectation, more of an invitation/suggestion. At one point this had text along the lines of "may choose to", but that was felt to be a bit weak. There was some discussion about making this "are RECOMMENDED to move", but that was felt to be too strong (and who the hell are we to tell 'em what to do anyway?!). This was the happy medium we settled on. Good enough? [Roman] Yes. I figured there long deliberation on a few set of words. Section 3.2. Item #3. Editorial. s/Writers of name resolution APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or “designers” Thank you - I've updated this to be "Developers" in Pull Request #46. Backstory: This section "answers" the questions from RFC6761, and Q 3 was phrased as: "3. Name Resolution APIs and Libraries: Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?" We'd just sort of followed along from the language. ** Section 3.2. Item #7 7. DNS registries/registrars for the global DNS will never register names in the .alt pseudo-TLD because .alt will not exist in the global DNS root. Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear. This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language. Is there a reason for that? Yup, actually 2 reasons: 1: .alt will not exist in the DNS, and so it's not possible for DNS registries and registrars to register DNS names. We don't tell pigs that they MUST NOT fly, and so telling registries and registrars that they MUST NOT do something that they are unable to seemed odd. But, Paul Wouters also pointed at this text in his ballot, and that it is unclear, so I've suggested (in PR 46) this instead: "7. It is not possible for DNS registries/registrars to register DNS names in the .alt pseudo-TLD as the .alt will not exist in the global DNS root." 2: there is some sensitivity here. ICANN regulates registries and registrars, and I was trying to be extra careful to not accidentally step on toes and imply that the IETF was telling 'em what to do… [Roman] Understood. Roman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ -- COMMENT: -- Thank you to Linda Dunbar for the SECDIR review. ** Section 2. Currently deployed projects and protocols that are using pseudo-TLDs are recommended to move under the .alt pseudo-TLD, but this is not a requirement. I don’t understand the basis of this recommendation. Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance. Why is there an expectation that this document can change behavior? Section 3.2. Item #3. Editorial. s/Writers of name resolution APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or “designers” ** Section 3.2. Item #7 7. DNS registries/registrars for the global DNS will never register names in the .alt pseudo-TLD because .alt will not exist in the global DNS root. Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear. This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language. Is there a reason for that? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ -- COMMENT: -- Thank you to Catherine Meadows for the SECDIR review. I support Murray Kucherawy DISCUSS position. ** Section 3. Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation. Can “meaningless” be more formally described? Are there specific RR which shouldn’t be in the catalog? ** Section 3. Editorial. The content of catalog zones may not be accessible from any recursive nameserver. Can the intent of this be clarified? Is it saying that the “contents of the catalog zone may _not necessarily_ be accessible from _all or some_ recursive nameservers”? or the “contents of the catalog zone _should not be/must not be_ accessible from any recursive nameserver”? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ -- DISCUSS: -- (updated ballot) The IETF has steered away from publishing protocol mechanisms with dependencies on national cryptography as we do not have the ability to validate their security properties ourselves. IETF stream documents typically rely on documents published in the Crypto Forum Research Group (CFRG) [1]; an open and peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to give us confidence in cryptographic algorithm choices. Since the described GOST mechanism doesn’t fit into these vetting criteria and the WG (based on the shepherd’s report) has not provided alternative analysis, it is not appropriate to publish this document in the IETF stream. 11/28/2022: Suggested resolution per mailing list discussion: https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/ -- COMMENT: -- Thank you to Mohti Sethi for the SECDIR review. I have no insight into the deliberations in 2010 that resulted in RFC5933 being published. However, as the shepherd’s report notes, with the publication of RFC6014 (in 2010) and RFC9157 (in 2021), the relevant IANA DNSSEC registries [4] [5] provide sufficient flexibility to assign code points with an RFC outside of the IETF stream (a situation that didn’t exist in 2010). Such flexible policies in DNSSEC registries have also been made for TLS and IPsec registries to avoid the IETF having to render judgement on cryptography, national or otherwise, while still providing code points -- the exact situation we find ourselves in. Similar GOST-related protocol mechanisms have successfully been submitted to the Independent Submission Stream (ISE) [3] (e.g., RFC 9189, draft-smyslov-ike2-gost, and draft-smyshlyaev-tls13-gost-suites). It seems possible to follow the same approach here. [1] https://datatracker.ietf.org/rg/cfrg/about/ [2] https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel [3] https://www.rfc-editor.org/about/independent/ [4] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 [5] https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Roman Danyliw's Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)
Hi! > -Original Message- > From: iesg On Behalf Of Paul Hoffman > Sent: Thursday, November 17, 2022 7:06 PM > To: Roman Danyliw > Cc: The IESG ; draft-ietf-dnsop-rfc5933-...@ietf.org; dnsop- > cha...@ietf.org; dnsop@ietf.org; Tim Wicinski > Subject: Re: [Ext] [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop- > rfc5933-bis-12: (with DISCUSS and COMMENT) > > On Nov 17, 2022, at 3:02 PM, Roman Danyliw via Datatracker > wrote: > > -- > > DISCUSS: > > -- > > > > The IETF has steered away from publishing protocol mechanisms with > dependencies > > on national cryptography as we do not have the ability to validate their > > security properties ourselves. IETF stream documents typically rely on > > documents published in the Crypto Forum Research Group (CFRG) [1]; an > open and > > peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to > give > > us confidence in cryptographic algorithm choices. Since the described GOST > > mechanism doesn’t fit into these vetting criteria and the WG (based on the > > shepherd’s report) has not provided alternative analysis, it is not > > appropriate > > to publish this document in the IETF stream. > > [snip] > It feels like this DISCUSS ballot is asking for a non-IETF-stream RFC to > obsolete > an IETF-stream RFC. Yuck. Instead, it might be better to publish this in the > IETF > stream; separately, the IESG could then publish a statement that future > national algorithm documents should not come through the IETF stream. I agree that we need to be careful on what a non-IETF stream document would do to an IETF-stream document. As a counter proposal, I would recommend that we use the flexibility afforded by RFC6014 and RFC9157 to address our current situation, and split the document. The document has several components: (a) Specification of and guidance for new DNSKEY and RRSIG behavior using GOST R 34.10-2012 and GOST R 34.11-2012 (i.e., Section 2 - 6, 9) (b) Guidance to obsolete/update previous RFC5933/RFC8624 behavior per (a) (i.e., Section 7, 8) (c) Request new IANA registry entries for (a) (i.e., Section 10) (d) Request updates to IANA registries to deprecate older GOST code points specified by IETF-stream documents (i.e., Section 10) Components (a) and (c) could be extracted from this document and added to a new document published by the ISE. This text is the new national crypto that the WG cannot render judgement on per my DISCUSS. The remaining text, components (b) and (d), would be the reduced draft-ietf-dnsop-rfc5933-bis document and would reference this new ISE document with the appropriate caveats on the confidence the WG in this new ISE reference. This reduced draft-ietf-dnsop-rfc5933-bis document would be the compromise where an IETF-stream document is needed to redefine previously specified behavior so that an ISE-stream document wouldn't have to obsolete an IETF-stream one. If (when) GOST R 34.10-2012/GOST R 34.11-2012 is superseded (and assuming it remains national crypto), algorithm revisions can be handled entirely by the ISE. Regards, Roman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ -- DISCUSS: -- The IETF has steered away from publishing protocol mechanisms with dependencies on national cryptography as we do not have the ability to validate their security properties ourselves. IETF stream documents typically rely on documents published in the Crypto Forum Research Group (CFRG) [1]; an open and peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to give us confidence in cryptographic algorithm choices. Since the described GOST mechanism doesn’t fit into these vetting criteria and the WG (based on the shepherd’s report) has not provided alternative analysis, it is not appropriate to publish this document in the IETF stream. -- COMMENT: -- Thank you to Mohti Sethi for the SECDIR review. I have no insight into the deliberations in 2010 that resulted in RFC5933 being published. However, as the shepherd’s report notes, with the publication of RFC6014 (in 2010) and RFC9157 (in 2021), the relevant IANA DNSSEC registries [4] [5] provide sufficient flexibility to assign code points with an RFC outside of the IETF stream (a situation that didn’t exist in 2010). Such flexible policies in DNSSEC registries have also been made for TLS and IPsec registries to avoid the IETF having to render judgement on cryptography, national or otherwise, while still providing code points -- the exact situation we find ourselves in. Similar GOST-related protocol mechanisms have successfully been submitted to the Independent Submission Stream (ISE) [3] (e.g., RFC 9189, draft-smyslov-ike2-gost, and draft-smyshlyaev-tls13-gost-suites). It seems possible to follow the same approach here. [1] https://datatracker.ietf.org/rg/cfrg/about/ [2] https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel [3] https://www.rfc-editor.org/about/independent/ [4] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 [5] https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-dnssec-bcp-05: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dnssec-bcp-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ -- COMMENT: -- Thank you to Catherine Meadows for the SECDIR review. ** Section 1.1 Recent estimates are that fewer than 10% of the domain names used for web sites are signed, and only around a third of queries to recursive resolvers are validated. Since this is a point-in-time measurement, this document would age better with a reference to these figures. ** Section 1.1 However, this low level of implementation does not affect whether DNSSEC is a best current practice; it just indicates that the value of deploying DNSSEC is often considered lower than the cost. Nonetheless, the significant deployment of DNSSEC beneath some top- level domains (TLDs), and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone, demonstrate that DNSSEC is suitable for implementation by both ordinary and highly sophisticated domain owners. Editorial style. The first sentence states that most of the Internet doesn’t see the value of DNSSEC relative to the cost. The second sentence suggests that it is “suitable for … ordinary domain owners.” I might have used the word “applicable for …” because for me, part of suitability is that it is that the cost is acceptable for many in the target population (which the first sentence suggests it is not) ** Section 2. Earlier iterations have not been deployed on a significant scale. Consider if the text can qualify the differences in scale from the one posed on Section 1.1 (i.e., <10% of the domain). ** Section 3. Cryptography improves over time, and new algorithms get adopted by various Internet protocols. Consider rephrasing this statement. Overtime, existing cryptographic algorithms typically weaken as computing power and new cryptoanalysis emerges. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ -- COMMENT: -- ** I support Paul Wouter’s DISCUSS position. Like Alvaro and Francesca also commented, this document appears to be changing the behavior of RFC5155. It should formally update it in the meta data. Specifically: -- The language in Section 3.2. appears to “weaken” the guidance in Section 10.3 of RFC5155 -- Section 3.2 also seems to explicitly say it is updating RFC5155 with “[n]ote that this specification updates [RFC5155] …” ** Section 2. The following sections describe recommendations for setting parameters for NSEC3 and NSEC3PARAM. I don’t believe this is accurate. There are few tangible recommendations about iterations or salts in this section. That’s in Section 3. ** Section 2.2. In general, NSEC3 with the Opt-Out flag enabled should only be used in large, highly dynamic zones with a small percentage of signed delegations. Operationally, this allows for fewer signature creations when new delegations are inserted into a zone. This is typically only necessary for extremely large registration points providing zone updates faster than real-time signing allows or when using memory-constrained hardware Qualitative scales such as “large … dynamic zones” and “extremely large registration points” used. Can the operational experience informing these statements be cited to suggest the scale? ** Section 3.1. Operators are encouraged to forgo using a salt entirely by using a zero-length salt value instead (represented as a "-" in the presentation format). Section 2.4 seemed to take a stronger position on the lack of utility of the salt. Is there a reason normative language isn’t being used? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ -- COMMENT: -- Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my manual review of such syntax might be rusty): -- What role does “value = *OCTET” play in the specification of SvcParams? It doesn’t appear to be used or explained. -- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal syntax of the entire parameter which is a list of SvcParam)? -- (Editorial) To make it clear that “char-string” is defined in Appendix A, it would be helpful to: OLD SvcParamValue = char-string NEW SvcParamValue = char-string; per Appendix A ** Section 3.1. Recommend explicit saying which connection should be abandoned – s/the client SHOULD abandon the connection attempt/the client SHOULD abandon the connection attempt to the target service/ ** Section 7.4. Unpacking the first paragraph for easier commentary: (a) The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. (b) If A and records for TargetName are locally available, the client SHOULD ignore these hints. (c) Otherwise, clients SHOULD perform A and/or queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. (a) seems to be saying that the value of the SrcParamValue is going to return an IP address associated with a TargetName. (b) seems to be saying that if the client already has an IP address for the TargetName in the cache, then ignore the hints. Per (c), why would A/ queries need to be performed to resolve TargetName? Isn’t the hint the associated IP address? ** Section 9.3. Editorial. s/the the/the/ ** Section 10. Editorial. s/the value of the parameter is an ECHConfigList [ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH] ** Section 10. Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList in Section 7.1.2/ ** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/ ** Section A.1 Per the ABNF: -- What role does “item” rule play? It’s not referenced or explained. (see below) -- It would be useful to state somewhere which ABNF rule corresponds to which form of the list. Perhaps something like: OLD For implementations that allow "," and "\" in item values, the following escaping syntax applies: NEW For implementations that allow "," and "\" in item values, the ‘comma-separated’ rule for the escaping syntax applies. For those that do not required escaping, the ‘item’ syntax rule applies. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Hi Duane! > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: Thursday, October 28, 2021 5:58 PM > To: Roman Danyliw > Cc: draft-ietf-dnsop-dns-tcp-requireme...@ietf.org; dnsop@ietf.org; Suzanne > Woolf ; dnsop-cha...@ietf.org; The IESG > > Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp- > requirements-13: (with DISCUSS and COMMENT) > > Hi Roman, thanks for the review. My responses are inline. > > > On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker > wrote: > > > > > > > > -- > > DISCUSS: > > -- > > > > This document has a dedicated section for DNS over TLS, makes a number > > of configuration recommendations for DoT, and notes it in the Privacy > > Considerations. However, there is no mention of DNS over HTTPS (DoH). > > It seems like DoH should get similar treatment. > > Speaking only for myself, I am reluctant to include DoH in this draft. I > feel that > TCP and TLS are similar enough that it makes sense to cover both, but DoH is > quite a bit different. No argument that DoH is a bit unlike the others. > If there is a concern that mentioning DoT is unfair and DoH should get equal > time then I would be in favor of discussing encrypted DNS transports more > generally, or perhaps even cutting back on encrypted transport references. I believe that if this draft is going to be the BCP to discuss DNS over TCP, all of the flavors of DNS over TCP need to be covered. I think it would be a disservice to the existing guidance to cut out discussion of encrypted transport. As you propose, I don't see a reason why the different encrypted transports couldn't be discussed together. I leave it to the deep expertise in the WG to ensure that nuances between DoT and DoH, when relevant, are called out. > But if Im in the minority here and the working group and IESG would like to > see > DoH included then we can figure out what to say. > > > > > > > -- > > COMMENT: > > -- > > > > Thank you to Alan DeKok for the SECDIR review. > > > > ** Section 2.2. > > Yet, defying some expectations, DNS over TCP remained little-used in > > real traffic across the Internet around this time. > > > > This section doesn’t define a time period to associate with “… around > > this time”. > > Does “…in the late 1990s” work for you? Yes, thanks. > > > > > ** Section 2.2. > > Around the time > > DNSSEC was first defined, another new feature helped solidify UDP > > transport dominance for message transactions. > > > > Is that “new feature” EDNS(0) per Section 2.3? > > Yes, its a lead-in to the next section. Do you think the text needs to be > different here? No, you can leave the text as is. > > > > ** Section 2.5 > > Today, the majority of the DNS community expects, or at least has a > > desire, to see DNS over TCP transactions occur without interference. > > > > Is there a citation for this assertion? > > How about the 2020 DNS flag day? Https://dnsflagday.net/2020/ Works for me. > > ** Section 2.5. Per the use of [CHES94] and [DJBDNS] to motivate the > > position that DNS over TCP is not needed, are there more modern > > references? The former is from 1994, and the latter appears to be last > updated in 2002. > > I’m not aware of any newer, better references. It does show how long held > these beliefs are. No problem. I wanted to check. > > > > ** Section 3. > > Lastly, Section 1 of [RFC1536] is updated to eliminate the > > misconception that TCP is only useful for zone transfers. > > > > With what text is Section 1 of [RFC1536] updated? > > I suppose my suggestion would be to strike this sentence: > >UDP is, therefore, the chosen protocol for communication >though TCP is used for zone transfers. > > Later in section 1 there is a "Since UDP is used," which could be changed to > "When UDP is used," if necessary. Could you make it cleared exactly what is the old and new text relative to RFC1536. > > > > > ** Section 4.1. Consider adding a reference of SYN cookies. > > I added a reference to https://en.wikipedia.org/wiki/SYN_cookies I would recommend using Section 3.6 of RFC4987 instead. Everything else below looks good. Thanks. Regards, Roman > > > > **
Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Hi John! > -Original Message- > From: iesg On Behalf Of John Scudder via Datatracker > Sent: Thursday, October 28, 2021 9:42 AM > To: The IESG > Cc: draft-ietf-dnsop-dns-tcp-requireme...@ietf.org; dnsop@ietf.org; dnsop- > cha...@ietf.org; suzworldw...@gmail.com > Subject: John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements- > 13: (with COMMENT) > > John Scudder has entered the following ballot position for > draft-ietf-dnsop-dns-tcp-requirements-13: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ > > > > -- > COMMENT: > -- [snip] > 3. Section 6 says applications should perform “full TCP segment reassembly”. > What does that mean? A quick google search doesn’t suggest it’s a well-known > term of art. I'm guessing that what you mean is that the applications should > capture (and log, etc) the bytestream that was segmented and transmitted by > TCP? I'll let the authors speak to this, but I think this means full TCP stream reassembly -- that is analyze, the reassembled stream, not the individual packets. There is a long history of evasion attacks in network security analysis tools when individual fragments/packets are analyzed instead of the reassembled streams. Roman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ -- DISCUSS: -- This document has a dedicated section for DNS over TLS, makes a number of configuration recommendations for DoT, and notes it in the Privacy Considerations. However, there is no mention of DNS over HTTPS (DoH). It seems like DoH should get similar treatment. -- COMMENT: -- Thank you to Alan DeKok for the SECDIR review. ** Section 2.2. Yet, defying some expectations, DNS over TCP remained little-used in real traffic across the Internet around this time. This section doesn’t define a time period to associate with “… around this time”. ** Section 2.2. Around the time DNSSEC was first defined, another new feature helped solidify UDP transport dominance for message transactions. Is that “new feature” EDNS(0) per Section 2.3? ** Section 2.5 Today, the majority of the DNS community expects, or at least has a desire, to see DNS over TCP transactions occur without interference. Is there a citation for this assertion? ** Section 2.5. Per the use of [CHES94] and [DJBDNS] to motivate the position that DNS over TCP is not needed, are there more modern references? The former is from 1994, and the latter appears to be last updated in 2002. ** Section 3. Lastly, Section 1 of [RFC1536] is updated to eliminate the misconception that TCP is only useful for zone transfers. With what text is Section 1 of [RFC1536] updated? ** Section 4.1. Consider adding a reference of SYN cookies. ** Section 5.1. Does the term “DNS Wedgie” have to be used here given its use in American English as the name for a bullying practice? Judging from a google search (https://www.google.com/search?q="dns+wedgie";), this document appears to be inventing the term in the context of DNS. ** Section 6. Per “Furthermore, as with real TCP, …”, what is “real TCP”? ** Section 9. Because TCP is somewhat more complex than UDP, some characteristics of a TCP conversation may enable fingerprinting and tracking that is not possible with UDP. Recommend being clearer on who is being fingerprinted – s/fingerprinting/DNS client fingerprinting/ ** Section 9. The text “DNS over TLS or DTLS is the recommended way to achieve DNS privacy” seems rather soft on recommending encrypted DNS of any flavor. Was there any WG conversation to same something stronger? ** Section 9. The text mentions that TCP is more susceptible to fingerprinting. It would be also be worth mentioned that using DoH reduces susceptibility to traffic analysis. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
Hi Lada! > -Original Message- > From: Ladislav Lhotka > Sent: Friday, June 4, 2021 3:20 AM > To: Roman Danyliw ; The IESG > Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; be...@nlnetlabs.nl; be...@nlnetlabs.nl > Subject: Re: Roman Danyliw's No Objection on draft-ietf-dnsop-iana-class-type- > yang-03: (with COMMENT) > > Hi Roman, > > thanks for your comments, please see below. > > Roman Danyliw via Datatracker writes: > > ... > > > -- > > COMMENT: > > -- > > > > Thank you to Valery Smyslov for the SECDIR review. > > > > I applaud the clever use of XSLT to autogenerate and keep the YANG > > module up to date. > > > > ** Section 5. Recommend refining the security considerations to defer > > security issues to the modules that use import the data types defined in > > this > document. > > Roughly: > > > > OLD > > This documents translates two IANA registries into YANG data types > >and otherwise introduces no technology or protocol. Consequently, > >there are no security issues to be considered for this document. > > > > NEW > > > > This document translates two IANA registries into YANG data types for > > use by other YANG modules. When imported and used, the resultant > > module schema will have data nodes that can be writable or readable > > via a network management protocol. Access or modification to such > > data nodes may be considered sensitive in some network environments, > > and this risk should be evaluated by the importing module. > > > > The iana-dns-class-rr-type module only defines data types, so it doesn't > contribute any data nodes when imported or used. I suggest to use the > following formulation, adopted from RFC 6991: > > NEW > This documents translates two IANA registries into YANG data types and > otherwise introduces no technology or protocol. The definitions themselves > have no security impact on the Internet, but their use in concrete YANG > modules might have. The security considerations spelled out in the YANG > specification [RFC7950] apply for this document as well. > > Is it sufficient? Works for me! Thanks for the improvement. Regards, Roman > Thanks, Lada > > > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-iana-class-type-yang-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ -- COMMENT: -- Thank you to Valery Smyslov for the SECDIR review. I applaud the clever use of XSLT to autogenerate and keep the YANG module up to date. ** Section 5. Recommend refining the security considerations to defer security issues to the modules that use import the data types defined in this document. Roughly: OLD This documents translates two IANA registries into YANG data types and otherwise introduces no technology or protocol. Consequently, there are no security issues to be considered for this document. NEW This document translates two IANA registries into YANG data types for use by other YANG modules. When imported and used, the resultant module schema will have data nodes that can be writable or readable via a network management protocol. Access or modification to such data nodes may be considered sensitive in some network environments, and this risk should be evaluated by the importing module. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-nsec-ttl-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ -- COMMENT: -- Thank to Tiru Reddy for the SECDIR review. Section 5. Per: An attacker can prevent future records from appearing in a cache by seeding the cache with queries that cause NSEC or NSEC3 responses to be cached, for aggressive use purposes. This document reduces the impact of that attack in cases where the NSEC or NSEC3 TTL is higher than the zone operator intended. Shouldn’t this text read s/An attacker can prevent future records/An attacker can delay future records/? Per Section 9 of RFC8198, “If the resolver is making aggressive use of NSEC/NSEC3, one successful attack would be able to suppress many queries for new names, up to the negative TTL." If the timing is right, this delay could be indefinite. Isn't the mitigation provided here that the attacker needs to seed the cache more often? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-server-cookies-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ -- COMMENT: -- Thank you to Stephen Farrell for the SECDIR review (https://mailarchive.ietf.org/arch/msg/secdir/TV4Qw2ionRmJ8skKzgUWzRTeDtw/) and the discussion around the appropriateness of SipHash, the associated reference and the arithmetic around the timestamp. A few comments on this thread relevant as COMMENTs: * Please do make clarifying editorial fixes noted here https://mailarchive.ietf.org/arch/msg/secdir/eGSBMIwkaJjOy9EXtw5lqcgrZRM/ * Thanks for exploring URLs for the normative reference for for SipHash, but pointing to a personal website is not appropriate (despite it providing a direct link to the relevant paper). Please use an authoritative citation in Section 4.4. I recommend (something to the effect of): Aumasson JP., Bernstein D.J. SipHash: A Fast Short-Input PRF. Progress in Cryptology - INDOCRYPT 2012. Lecture Notes in Computer Science, vol 7668. Springer. https://doi.org/10.1007/978-3-642-34931-7_28. As an aside, while I concur with the sentiment that all crypto algorithms used in standards track protocols should be reviewed by CRFG (https://mailarchive.ietf.org/arch/msg/secdir/wZq9M2c3hrd5SpOc1KAM3TuPH0w/) as a standard practice, this isn’t where we are as a community as of yet. This needed review of SipHash can be decoupled from this document. Additionally: ** Please also be clear on the notation that SipHash2.4. Since the normative reference uses the notation “SipHash-2-4” (with the dashes), please use that or provide explicit text to explain it. ** Section 7. For future agility, should a “recommended” column be sub-registry just as was added to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 or is the thinking that there will only be serial updates of the cookie algorithm where concurrent use is not expected? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Hi Duane! > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: Wednesday, October 14, 2020 8:28 AM > To: Roman Danyliw > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop-cha...@ietf.org; dnsop@ietf.org; Wessels, Duane > ; The IESG > Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: > (with DISCUSS and COMMENT) > > > > > On Oct 12, 2020, at 9:24 AM, Roman Danyliw wrote: > > > > Hi Duane! > > > > Thanks for the extensive changes in -13. They address my concerns. I have > left one remaining comment about clarifying "provably secure" with a > reference. Otherwise, I've cleared my ballot. > > Thanks Roman, > > Instead of "provably secure," how does this look to you: > >1. The verifier MUST first determine whether or not to expect DNSSEC >records in the zone. By examining locally configured trust >anchors, and, if necessary, querying for and validating DS RRs in >the parent zone, the verifier knows whether or not the zone to be >verified should include DNSSEC keys and signatures. For zones >where signatures are not expected, or if DNSSEC validation is not >performed, digest verification continues at step 4 below. > >2. For zones where signatures are expected, the existence of the >apex ZONEMD record MUST be validated. If the DNSSEC data proves >the ZONEMD RRSet does not exist, digest verification cannot >occur. If the DNSSEC data proves the ZONEMD does exist, but is >not found in the zone, digest verification MUST NOT be considered >successful. > >3. For zones where signatures are expected, the SOA and ZONEMD >RRSets MUST have valid signatures, chaining up to a trust anchor. >If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest >verification MUST NOT be considered successful. This language looks good to me and is even better than a reference. Thanks for clarifying the text further. Roman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Hi Duane! Thanks for the extensive changes in -13. They address my concerns. I have left one remaining comment about clarifying "provably secure" with a reference. Otherwise, I've cleared my ballot. Regards, Roman > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: Friday, October 9, 2020 2:40 PM > To: Roman Danyliw > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop-cha...@ietf.org; dnsop@ietf.org; Wessels, Duane > ; The IESG > Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: > (with DISCUSS and COMMENT) > > > > > On Oct 7, 2020, at 1:52 PM, Roman Danyliw wrote: > > > > > > In that case (where no assumptions are made about the transport), it seems > that only these scenarios from the list above apply: > > > > With an on-path attacker (and trusted server hosting the zone file) > > > > ** No DNSSEC = integrity: NO; authenticity = NO > > ** DNSSEC = integrity: YES; authenticity = YES > > > > With a rogue server hosting the zone file (but is not the operator of the > > zone) > > > > ** No DNSSEC = integrity: NO; authenticity = NO > > ** DNSSEC = integrity: YES; authenticity = YES > > > > Or more succinctly, without DNSSEC, the two stated security properties > > aren't > provided. > > > > I'm not sure of what the best way is to resolve this mismatch based on the > use cases. I can see (at least) two paths to resolution: > > > > (1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will > preserve the authenticity and integrity properties described in Section 1.1. > and > 6. An additional step or two might be needed to the verification process in > Section 4. Does this impact the planned use cases or workflows? > > > > (2) Provide appropriate caveats that ZONEMD information may not mean > what you think it means depending on whether DNSSEC is used. This likely > means: the motivational goal in Section 1.1 may need to be weakened; the > analysis of alternatives in Section 1.2 won't make sense (for the non-DNSSEC > case); and an appropriate applicability-like statement might also be necessary > to describe how to use an insecure checksum. Section 6 would needs > additional language to capture the difference between the DNSSEC vs. non- > DNSSEC deployment. Editorially, clearer words like checksum might also help. > > Thanks Roman, I see your point. With the help of my coauthors we have made > some edits that I think will address your concerns. > Rather than try to include them all here, it will probably be easier to read > the > diff of the next revision that we hope to > submit later today. Alternatively I can give you a github pull request link > showing the changes if that would be helpful. > > DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Hi Duane, > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: Wednesday, October 7, 2020 3:55 PM > To: Roman Danyliw > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG > > Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: > (with DISCUSS and COMMENT) > > Hi Roman, thanks for the detailed review and comments. My responses are > inline. > > > > On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker > wrote: > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://secure- > web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLw > mmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84 > DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ > 9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L- > eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc- > a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg% > 2Fstatement%2Fdiscuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://secure- > web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR- > caNTg- > liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2m > ywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsj > sae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm > 4JcgBjaAU2ABRPZ- > bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf- > dnsop-dns-zone-digest%2F > > > > > > > > -- > > DISCUSS: > > -- > > > > Section 6.1. My read of the text is that the security properties are > > intended > > to be independent of the transport protocol. With that assumption and the > > validation procedures in Section 4, I need help understanding the security > > properties the client can rely on in the absence of DNSSEC. Consider the > > following scenarios and attacker types; and the assurances a client could > > have > > when retrieving the zone file from the server: > > > > With an on-path attacker (and trusted server hosting the zone file) > > > > ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO > > > > ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker); > > authenticity = NO > > > > ** DNSSEC = integrity: YES; authenticity = YES > > > > With a rogue server hosting the zone file (but is not the operator of the > > zone) > > > > ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO > > > > ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO > > > > ** DNSSEC = integrity: YES; authenticity = YES > > > > The text states that: > > > > The zone digest allows the recipient of a zone to verify its > > integrity. In conjunction with DNSSEC, the recipient can > > authenticate that it is as published by the zone originator. > > > > Can the means to realize integrity without DNSSEC unless there is a reliance > on > > transport security of some form be clarified. Minimally, it seems like this > > section needs cautionary text (likely with normative language) to the > > effect of > > “ZONEMD information from zone files lacking DNSSEC support or that were > shared > > over ‘unsecure transport’ cannot be relied upon for cryptographic integrity > > assurance.” > > You are correct that we intend the security properties to be independent of > any transport protocol. I'm reluctant to suggest in this document that > a recipient could rely on ZONEMD for integrity because it came over a secure > transport. Although that might be true, I have to think that the secure > transport itself provides the integrity assurance, and not the ZONEMD record. In that case (where no assumptions are made about the transport), it seems that only these scenarios from the list above apply: With an on-path attacker (and trusted server hosting the zone file) ** No DNSSEC = integrity: NO; authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES With a rogue serv
[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ -- DISCUSS: -- Section 6.1. My read of the text is that the security properties are intended to be independent of the transport protocol. With that assumption and the validation procedures in Section 4, I need help understanding the security properties the client can rely on in the absence of DNSSEC. Consider the following scenarios and attacker types; and the assurances a client could have when retrieving the zone file from the server: With an on-path attacker (and trusted server hosting the zone file) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker); authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES With a rogue server hosting the zone file (but is not the operator of the zone) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES The text states that: The zone digest allows the recipient of a zone to verify its integrity. In conjunction with DNSSEC, the recipient can authenticate that it is as published by the zone originator. Can the means to realize integrity without DNSSEC unless there is a reliance on transport security of some form be clarified. Minimally, it seems like this section needs cautionary text (likely with normative language) to the effect of “ZONEMD information from zone files lacking DNSSEC support or that were shared over ‘unsecure transport’ cannot be relied upon for cryptographic integrity assurance.” -- COMMENT: -- Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). ** Section 1. s/allowing verification of the zone/allowing verification of the integrity of the zone/ ** Section 1.2. In the discussion about alternatives, it seems like the two competing designs are “channel security” vs. “data security”? Is the latter the equivalent to “object security”, a term with which I’m more familiar? That is, the data itself carries a set of security properties independent of the channel or session exchanging it. ** Section 1.3. Clarifying language. OLD As specified herein, the digest is re-calculated over the entire zone content each time NEW As specified herein, the digest is re-calculated over the entire zone content each time the zone is updated. ** Section 1.3. Editorial. The sentence “It is, however, extensible so future schemes to support incremental zone digest algorithms (e.g. using Merkle trees) can be accommodated” didn’t parse for me. ** Section 2. Per the support of multiple ZONEMD RRs, what is meant by “rollovers”? There are no keys here. It seems like multiple ZONEMD would be there for algorithm agility (mentioned) and scheme agility. ** Section 2.0. When multiple ZONEMD RRs are present, each must specify a unique Scheme and Hash Algorithm tuple Would a normative MUST be more appropriate here? ** Section 4. The numbered list calls zones “provably insecure” and “provable secure”. What is the precise definition of those terms. Unless there were formal methods involved, I’d recommend against using those words. ** Section 4. If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Schemes and Hash Algorithms is sufficient to verify the zone. It would likely be worth mentioning in Section 6 that when multiple algorithms are used, the overall security rests with the weakest one. ** Section 5.2 and 5.3 Shouldn’t there be a request for a sub-registry, not a web page? For Section 5.2: OLD IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: NEW IANA is requested to create a new sub-registry in the "Domain Name System (DNS) Parameters" registry as follows: ** Section 5.2. It would likely be helpful to clarify the purpose of the fields (e.g., it wasn’t obvious to me initially that “Implementati
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-extended-error-14: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-extended-error-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ -- COMMENT: -- ** Thanks for responding to the SECDIR review (and thanks Catherine Meadows for the review). I recommend applying the proposed text (suggested by Wes) to the Security Considerations that resulted from the discussion. For me, it strikes a balance. ** Section 4.5. Code = 4 (Forged answer) rolls up into a single code a number of rationales as to why the answer was forged (e.g., legal vs. malware). However, when the request is blocked via blacklist, separate codes are not defined to convey the rationale. Why isn’t there symmetry? ** Section 6. Per the example of [RFC2845] and [RFC8094] as being approaches where DNS answer could be authenticated, consider adding RFC8484 to the list too. ** Editorial Nits: -- Section 1. Typo. s/These extended DNS error codes described in this document and can be used … /These extended DNS error codes described in this document can be used …/ -- Section 2. Typo. s/ The INFO-CODE serves as an index into the "Extended DNS Errors" registry Section 5.1./ The INFO-CODE serves as an index into the "Extended DNS Errors" registry defined in Section 5.1./ -- Section 4. s/… in the "Extended DNS Errors" registry Section 5.1 ./ … in the "Extended DNS Errors" registry defined in Section 5.1 ./ -- Section 4.9. s/but but/but/ -- Section 4.4. Typo. s/serever/server/ -- Section 7. “One author also wants to thank the band …”, is this really needed in an archival document? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-multi-provider-dnssec-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ -- COMMENT: -- Thank you for responding to the SECDIR review by Daniel Migault (and thanks for doing the review Daniel!) The proposed clarifications would be helpful. ** Per Section 6.1, “Provider A would generate a new ZSK and communicate their intent to perform a rollover …”, how is that communication done? Just as the Security Considerations already talks about API security, is there an analogous thing to say here in Section 12? ** Section 12. As key generation is invoked as a step in a number of these procedures, provide a pointer good practices for this step would be helpful, say Section 3.4.4 of RFC6781. ** Editorial Nits: -- A few places. Typo. s/Authentiated/ Authenticated/g -- Section 5.1. Typo. s/prefered/preferred/ -- Section 5.2. Typo. s/Aggresive/Aggressive/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-no-response-issue-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ -- COMMENT: -- Thanks for this document – it is allows for a very approachable way to verify conformance. ** Section 2. Per “Working around issues due to non-compliance with RFCs is not sustainable”, this seems like a bold statement. What is the basis for it? ** Section 4. This section repeats several times that firewall should not drop DNS traffic with unknown parameters and such traffic should not be construed as an attack. In the general case with “normal clients”, this is good advice. However, for certain highly controlled enclaves where a white-list-style approach to traffic is taken, this is not realistic. The presence of unexpected classes of new DNS traffic would be a bad sign (e.g., of compromise, a new software load whose features were not understood, or a configuration which was not validated) ** Section 8. For completeness, per “The test below use dig from BIND 9.11.0”, please provide a reference. ** Section 8 dig examples. It would be worth explaining $zone and $server. ** Section 10. Per “Testing protocol compliance can potentially result in false reports of attempts to break services from Intrusion Detection Services and firewalls.”, thanks for calling this out. I would recommend tuning this language: -- s/break services/attack services/ -- to acknowledge that uncommon DNS protocol fields or traffic (from this test regime) might trigger anomaly-detection/profile-based IDS alerts too ** Editorial Nits: -- Section 8. s/is know/is known/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-rfc2845bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ -- COMMENT: -- ** Section 1.3. Per “In 2017, two nameservers strictly following that document (and the related [RFC4635]) were discovered to have security problems related to this feature”, consider providing a reference to the published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) ** Section 6. Per “SHA-1 collisions have been demonstrated so the MD5 security considerations apply to SHA-1 in a similar manner. Although support for hmac-sha1 in TSIG is still mandatory for compatibility reasons, existing uses should be replaced with hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. -- It’s worth repeating those MD5 security considerations here -- (from Magnus Nystrom’s SECDIR review, thanks Magnus!) it’s worth including references to the recent SHA-1 cryptoanalysis provided in the SECDIR review -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). ** Section 10. Per “For all of the message authentication code algorithms listed in this document, those producing longer values are believed to be stronger”, as noted in Magnus’s SECDIR review, this could be misconstrued as the algorithm choice not the digest length provides the security. Recommend rephrasing (or making some statement ** Editorial -- Section 4.3.2. Per “When verifying an incoming message, this is the message after the TSIG RR and been removed and the ARCOUNT field has been decremented.”, this sentence doesn’t parse (is missing a word). -- Section 4.3.2. Per “A whole and complete DNS message in wire format.”, this isn’t a sentence. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-serve-stale-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ -- COMMENT: -- * I agree with Mirja, Section 8 is more informative than what is alluded to the paragraph starting with “Several recursive resolvers …” in Section 3, and IMO is worth keeping. I struck me as odd to call out the operation practice of a particular vendor (Akamai). We might want to check if this reference is ok – Ben? * A few reference nits: - Section 6. Per the mention to DNS-OARC, please provide a citation. - Section 6 and 9. The text references “during discussions in the IETF”. What is that specifically – WG deliberation? * Thanks for covering the attacker use cases of stale data in Section 10. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-obsolete-dlv-01: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-obsolete-dlv-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ -- COMMENT: -- ** Section 1. Is there a reference that can be cited to support the metric that 1389 of 1531 TLDs have secure delegation? ** Editorial. From idnits: The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '...he DLV mechanism SHOULD NOT be impleme...' ** Editorial -- The Table of Contents doesn’t appear to have generated the Section-to-Page Number mapping ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-algorithm-update-08: (with COMMENT)
Hi! From: Paul Wouters [mailto:pwout...@redhat.com] Sent: Wednesday, April 10, 2019 12:49 PM To: Roman Danyliw Cc: The IESG ; draft-ietf-dnsop-algorithm-upd...@ietf.org; Tim Wicinski ; dnsop-cha...@ietf.org; dnsop@ietf.org Subject: Re: Roman Danyliw's No Objection on draft-ietf-dnsop-algorithm-update-08: (with COMMENT) Thanks for the review! On Wed, Apr 10, 2019 at 5:30 PM Roman Danyliw via Datatracker mailto:nore...@ietf.org>> wrote: -- COMMENT: -- (1) Abstract. Nit. There is a reference, [RFC6944], in the abstract which isn’t permitted. Hmm, it is really just giving a clickable reference to the document we are obsoleting. It's kind of nice to have there. But I guess you are right that it is not allowed, so I've made the text without a reference. [Roman] Thanks. (2) Section 1.2, Per “This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended” ** Editorial: s/algorithms so weak that recommendation cannot be recommended/ algorithms so weak that they cannot be recommended/ Was fixed in -08 [Roman] Thanks. ** The first part of the sentence doesn’t appear to be consistent with the RFC2119 words in the Section 3.1 Table which also includes RECOMMENDED/MAY (which is neither MTI or NOT RECOMMENDED) It is recommended in lower case, not in 2119 meaning? [Roman] Ok. I didn’t read it like that. (3) Section 1.3, Typo, s/from from/from/ (4) Section 3.1, Typo, s/cryptographics/cryptographic/ Were already fixed. (5) Section 3.1, ED448 appears to be the only algorithm that doesn’t have treatment in even briefly describing its designated implementation recommendation. It does get mentioned in the beginning of the paragraph. But there isn't much to say really. It's there but just slightly stronger than 25519, so not really worth the effort. I think it is okay to leave it as motsly uninteresting, but if someone has some text, I'm fine with that too. (6) Section 3.1, The sentence “It is expected that ED25519 will become the future RECOMMENDED default algorithm …” is clear on the future. However, looking back at the table in this section, it wasn’t clear what the current default algorithm is. I've changed it a little bit to indicate this by adding a sentence here: RSASHA256 is in wide use and considered strong. It has been the default algorithm for a number of years and is now slowly being replaced with ECDSAP256SHA256 due to its shorter key and signature size, resulting in smaller DNS packets. [Roman] This is clearer. Thanks. (7) Section 3.2, The sentence “Operation recommendation for new and existing deployments.” Seems to stand alone or is missing some words. Should it be something along the lines of “This section provides operational recommendations …” I've removed the sentence. (8) Section 3.2, Typo, s/is RECOMMENDED/is the RECOMMENDED/ (9) Section 3.4, Editorial, s/The SHA-256/SHA-256/ Were already fixed in -08. (10) Section 4, Typo, s/seciton/section/ Fixed. (11) Section 5, Editorial, s/for the use of DNSSEC/for use in DNSSEC/ Fixed. The -09 should appear shortly with these fixes. [Roman] Thanks so much for closing the loop on these and making the changes. Thanks! Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-algorithm-update-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-algorithm-update-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ -- COMMENT: -- (1) Abstract. Nit. There is a reference, [RFC6944], in the abstract which isn’t permitted. (2) Section 1.2, Per “This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended” ** Editorial: s/algorithms so weak that recommendation cannot be recommended/ algorithms so weak that they cannot be recommended/ ** The first part of the sentence doesn’t appear to be consistent with the RFC2119 words in the Section 3.1 Table which also includes RECOMMENDED/MAY (which is neither MTI or NOT RECOMMENDED) (3) Section 1.3, Typo, s/from from/from/ (4) Section 3.1, Typo, s/cryptographics/cryptographic/ (5) Section 3.1, ED448 appears to be the only algorithm that doesn’t have treatment in even briefly describing its designated implementation recommendation. (6) Section 3.1, The sentence “It is expected that ED25519 will become the future RECOMMENDED default algorithm …” is clear on the future. However, looking back at the table in this section, it wasn’t clear what the current default algorithm is. (7) Section 3.2, The sentence “Operation recommendation for new and existing deployments.” Seems to stand alone or is missing some words. Should it be something along the lines of “This section provides operational recommendations …” (8) Section 3.2, Typo, s/is RECOMMENDED/is the RECOMMENDED/ (9) Section 3.4, Editorial, s/The SHA-256/SHA-256/ (10) Section 4, Typo, s/seciton/section/ (11) Section 5, Editorial, s/for the use of DNSSEC/for use in DNSSEC/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
