On Fri, Oct 6, 2023 at 8:54 AM Shumon Huque <shu...@gmail.com> wrote:
> 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. > > Thanks for explaining that. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
