Mahesh Jethanandani has entered the following ballot position for draft-ietf-dnsop-ds-automation-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-ds-automation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3, paragraph 0 > The guidelines for deploying DS automation set out in this document > are meant to achieve more uniform treatment across suffixes — > minimizing user surprise and providing baseline safety and uniformity > of behavior. They are also intended to prevent disruption of DNS and > DNSSEC functionality. At a minimum, compliance with this RFC > requires support for both DNSSEC bootstrapping [RFC9615] and > subsequent updates [RFC7344], [RFC8078] under the implementation > guidance below. The last sentence reads as a MUST-level compliance requirement but does not use BCP 14 language. If it is intended as normative, it should say "MUST support both…". If it is merely descriptive, the word "compliance" should be removed or rephrased. As written, it is ambiguous. Section 10, paragraph 0 > This document considers security aspects throughout, and has no > separate considerations. The document's subject matter — automated, authenticated modification of DS records — has non-trivial threat surfaces that are dispersed through the body of the document but never consolidated into a threat model. At a minimum, the Security Considerations should address: - Automated DS removal: Section 7 describes the conditions under which DS records are automatically deleted. The security implications — that a zone could be stripped of DNSSEC protection without the registrant's direct action — is not called out as a threat. - Authentication compromise: If an attacker gains control of child zone signing keys or nameservers, automated DS updates become an attack vector. The checks in Section 4.1 partially mitigate this, but the residual risk is not articulated. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 7.2.2, paragraph 4 > DS update has occurred. * An exception from this rule is when the entire DS > ^^^^^^^^^^^^^^ Did you mean "exception to"? Section 7.2.2, paragraph 14 > considerations. The document's subject matter — automated, authenticated mod > ^^^^^^^^^^^^^^ This phrase is redundant. Consider using "subject" to avoid wordiness. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
