Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Bob Harold <[e-mail]>]

On Thu, Oct 5, 2023 at 6:16 PM Paul Hoffman <[e-mail]> wrote:

> On Sep 14, 2023, at 18:46, Tim Wicinski <[e-mail]> 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?

-- 
Bob Harold