Hi Roy, See below at <DE>
On Tue, Jul 14, 2026 at 7:52 PM Roy Arends <[email protected]> wrote: > > > On 14 Jul 2026, at 18:08, Donald Eastlake <[email protected]> wrote: > > > > Hi, > > ... > > 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. > <DE> Almost... What if it determines the ADT state from a validated DNSKEY RRset and the TTL expires or it gets crowded out of cache and then it needs to do another referral out of the zone. Perhaps you would say that means it no longer has that information so it has to refetch the DNSKEY RRset but I could imagine an implementation that remembers this about a zone.. This slightly fuzzy timing case is why I had said that it must be "holding" the DNSKEY RRset in my comment above. > > 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) > <DE> OK. > > 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. > <DE> Yes, the draft is clear that unsigned zones are susceptible to injection attacks. My point was slightly more complex: If you inject NSs into a zone that has legitimate NSs then they compete on an equal footing with those legitimate NSs and you are slightly better off then if you inject Delegation Types into a zone that has legitimate NSs because the Delegation Types will completely eclipse the NSs that will then be ignored. > > 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.\ > <DE> OK. > > 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! > <DE> You're welcome, <DE> Thanks, Donald =============================== Donald E. Eastlake 3rd 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > 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]
