On Fri, Oct 6, 2023 at 8:20 AM Bob Harold <rharo...@umich.edu> wrote:
> > On Thu, Oct 5, 2023 at 6:16 PM Paul Hoffman <paul.hoff...@icann.org> > wrote: > >> On Sep 14, 2023, at 18:46, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> > We chairs heard back from the authors and we're pulling this working >> group last call. >> >> We have turned in a -01 that addresses the initial comments in the WG >> Last Call that the document had obvious labeled holes in it. One of those >> holes had an old label on it, but the others needed filling, and we have >> done that now. Whenever the chairs have another slot to start a WG Last >> Call, we think this is now ready for it. >> >> --Paul Hoffman >> > > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8109bis-01 > > 3.3. DNSSEC with Priming Queries > > The second paragraph confused me: > > "A machine-in-the-middle attack on the priming query could direct a > resolver to a rogue root name server. Note, however, that a validating > resolver will not accept responses from rogue root servers if they are > different from the real responses because the resolver has a trust anchor > for the root and the answers from the root are signed. Thus, if there is a > machine-in-the-middle attack on the priming query, the results for a > validating resolver could be a denial of service, or the attacker seeing > queries while returning good answers, but not the resolver's accepting the > bad responses." > > I took me a while to understand, but something like this is what I think > it means, a little more clearly to me: > > A rogue server could return the proper NS RRset and signature, but fake A > and AAAA records, since they are not signed, which would effectively block > access to the root zone. But when a request is made for other records in > the root zone (like delegation NS records for a TLD, its normal role in DNS > resolution), those records are DNSSEC signed and can be validated, so a > rogue server can only block service, not give wrong answers that pass > validation. > > Could something like that be included? > I don't think that's correct. A priming query is for the NS RRset at the root zone. Root servers will authoritatively answer that and return a signed root NS RRset, which can be authenticated by resolvers. The glue records however are unsigned and could be faked, so resolvers could still be directed to communicate with rogue servers. But they could detect that attack after the fact, by examining the subsequent responses from the rogue servers, and see if the parts in those responses that should be signed are actually signed correctly. Note that delegation NS records in a referral response are NOT signed (they are not authoritative data). What is signed is either a DS record (set) proving secure delegation to a signed TLD, or an NSEC record that proves insecure delegation to an unsigned TLD. I agree that the wording could be improved. I had trouble understanding that paragraph too. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
