Hi Roy, See at <<DE>>
On Wed, Jul 15, 2026 at 6:56 PM Roy Arends <[email protected]> wrote: > > On 15 Jul 2026, at 22:08, Donald Eastlake <[email protected]> wrote: > > 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. > > Ah, I see the nuance now. How about: > > On receiving 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. > > This way, the check is done on reception of the referral, before it is > stored, and before it is followed. Once it is stored, it can be re-used > without having to check the ADT flag. > <<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. > > I do see your point. However, this scenario assumes an unsigned delegating > zone and an adversary capable of injecting referral responses. Such an > adversary can already forge or replace the referral, redirect the resolver > to adversary-controlled servers, or deny service. While the resolver’s > behaviour differs when processing NS records versus Delegation Types, I do > not believe this materially changes the adversary's capabilities or the > security model. Adding this distinction in resolver behaviour adds > complexity without improving the document. DNSSEC remains the intended > defence against this class of attack. > <<DE>> Your argument that the effect I pointed out does not "materially" change the security situation is fairly reasonable. And I agree that mentioning it would add some (although I believe very little) complexity to the draft. So I will not argue this further and will consider that, although we have a very small but reasonable disagreement, I am satisfied that you have carefully considered my comment before rejecting it. <<DE>> Thanks, Donald =============================== Donald E. Eastlake 3rd 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] Hope this helps, and thanks again for taking the time to review it and > discuss it! > > Warmly, > > Roy >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
