Hi Mahesh,
Thank you for your review! Please see below.
On 5/20/26 23:51, Mahesh Jethanandani via Datatracker wrote:
----------------------------------------------------------------------
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.
Indeed, explicit is better than implicit. To be even more explicit, I think
this is best reflected in the particular recommendations sections 4-7. I've
made the following adjustments:
OLD
4.1. Recommendations
1. Entities performing automated DS maintenance MUST verify:
a. the unambiguous intent of each DS update request as per
[I-D.ietf-dnsop-cds-consistency], by checking its consistency
NEW
4.1. Recommendations
1. Entities performing automated DS maintenance MUST verify:
a. the unambiguous intent of each DS bootstrapping or update
request as per [I-D.ietf-dnsop-cds-consistency], by checking [...]
as well as
OLD
7.1. Recommendations
[...]
2. DS update requests MUST be executed at the next publication
opportunity after verification of their authenticity, regardless
NEW
7.1. Recommendations
[...]
2. DS bootstrapping and update requests MUST be executed at the next
publication opportunity after verification of their authenticity, [...]
I also adjusted a few other places where the document said "DS updates" when really
"DS bootstrapping and update requests" was meant.
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.
Fair. The method was introduced in RFC 8078 (Section 4) and is only included as
part of a larger package here. Nevertheless, I will add a note about this to
the Security Considerations.
I don't have text yet, and will draft it together with text on other security
considerations suggested by Deb (for coherency). I'll post the proposed text in
that thread.
- 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.
Also a good point. Same as above, I will post proposed text in Deb's review
thread.
-------------------------------------------------------------------------------
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"?
Done.
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.
This text is not part of the draft. Actually, it's part of your review (quoted
above) ;-)
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
