> On 14 Jul 2026, at 18:08, Donald Eastlake <[email protected]> wrote: > > Hi, > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > The summary of the review is Ready with Issues. > This draft defines a category of DNS Resource Records (RRs) to appear > at delegation points and be authoritative in the parent while > analogous to the DS RR and also specifies their handling. A range of RR types > is reserved. > Security > -------- > This draft has an excellent and, as far as I can see, complete > Security Considerations Section! The threat model is stated > explicitly, the attacks are enumerated, and the residual-risk analysis > is clear about the limits of protection. That is uncommon and > commendable.
Thank you Donald! > > Issues > ------ > These are really just questions: > Is a statement needed to the effect that, to be secure, a resolver > always needs to have obtained, validated, and be holding the DNSKEY > RRset with ADT flag from X before following a referral from X? The current text implies it, but I agree it needs to be explicit. How about replacing 6.2 with the following text before the text in 6.2: Before following a referral from a DNSSEC-signed delegating zone, a validating resolver MUST determine the authenticated state of the ADT flag from a validated DNSKEY RRset for that zone. Followed by the current text in 6.2: When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY RRset of the delegating zone, the validator MUST verify the Delegation Type RRsets in the Authority section of the referral against the Type Bit Maps of the NSEC or NSEC3 record that matches the delegated name. If any are absent, the referral MUST be considered tampered with, and the response MUST be ignored. > Is there a need to clearly state what a resolver does if a zone is > signed and has Delegation Types but whose DNSKEY does not have ADT > set? I think so. I think the following text captures it cleanly: When the DNSKEY-ADT flag is clear, this consistency check does not apply. The resolver processes the referral according to the procedures defined in Section 5. (To be added after the current text in 6.2) > Should the draft point out that it makes unsigned zones a bit less > secure from an injection attack? Currently injecting a referral > competes with the legitimate answer but by requiring NS RRs to be > ignored if there are Delegation Types, an injection can cause active > discard of legitimate NS RRs. Section 8.3 (Injection of Delegation Types) concludes with the text: In unsigned zones, no cryptographic protection against this attack is available. IMHO, it implies that it makes unsigned zones susceptible to injection attacks. > The threat model talks about resolver to authoritative name server but > not so much about stub to recursive or resolver to forwarder. I think > these are taken care of, but this threat aspect could be clearer. Ack. Delegation Extensions are about a specific area in DNS that relates to the resolving process, which is a process that stub resolvers and forwarders typically outsource to recursive resolvers, I could not find a specific threat against their processes. > Nits > ---- > Acknowledgements: contains an ellipsis that should probably be > replaced with a period. Will replace. > Feel free to ignore the following items which are just my opinions: > Consider adding bit numbers at the top of Figure 1 as in Figure 2. Will add. > It seems more complex than necessary to say, in Section 3, that > 0xF000-0xF1EF and 0xF1F0-0xF1FF are for Delegation Types. The only > difference is the assignment policy which is spelled out elsewhere. I > would just say that 0xF000-0xF1FF are allocated for Delegation > Types. I’m going to leave it as is. It makes it clear that there are two ranges. > Listing the two contiguous ranges in Section 3.1 seems OK > although probably "Section 3.1.1 updates that policy..." -> "Section > 3.1.1 and Section 3.1.2 update that policy...". Actually, there should be one range only in Section 3.1, which currently states: "Section 3.1.1 updates that policy to account for the Delegation Types subcategory and Section 9.4 specifies the criteria that apply to allocation requests within the ranges 0xF000-0xF1EF and 0xF1F0-0xF1FF.” However, 9.4 only applies to the first range and not the private range. Will remove the second range! > Section 5.2, 2nd paragraph: "all information" -> "all the > information" Will fix! Thanks Donald! Warmly, Roy > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
