Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc8109bis-04.txt

[Willem Toorop <[e-mail]>]

Thanks Paul,

I feel Section 3.3. "DNSSEC with Priming Queries" may not do the effects 
of redirected query traffic enough justice. RFC 8109 already didn't do 
it enough justice I think.

For starters, the second paragraph already assumes a 
"machine-in-the-middle" attack, but there may also be off-path attacks 
that manage to spoof priming responses. The first paragraph already 
states that the address records are not signed. I think that should be 
the emphasis of the attack vector. I have some alternative text 
proposals for the first two paragraphs. I will copy the original text as 
well, followed by my proposals.

For the first paragraph I would like to add that the NS RRset is signed 
and can be validated, so instead of:

> The resolver MAY set the DNSSEC OK (DO) bit. At the time of 
> publication, there is little use to performing DNSSEC validation on 
> the priming query. At the time this document is published, all root 
> server names end in "root-servers.net" and the AAAA and A RRsets for 
> the root server names reside in the "root-servers.net" zone. All root 
> servers are also authoritative for this zone, allowing priming 
> responses to include the appropriate root name server A and AAAA 
> RRsets. But, because the "root-servers.net" zone is not signed at the 
> time this document is published, these RRsets cannot be validated.
I propose this text:
> The root NS RRset is DNSSEC signed and can be validated by a DNSSEC 
> validating resolver. At the time this document is published, the 
> addresses for the names in the root NS RRset reside in the 
> "root-server.net" zone. All root servers are also authoritative for 
> this zone, allowing priming responses to include the appropriate root 
> name server A and AAAA RRsets. But, because the "root-servers.net" 
> zone is not signed at the time this document is published, these 
> RRsets cannot be validated. An attacker that is able to provide a 
> spoofed priming response can provide alternative A and AAAA RRsets and 
> fool a resolver into taking addresses under the control of the 
> attacker to be authoritative for the root zone.


Then, the second paragraph is all about how DNSSEC signed data cannot be 
modified undetected and can only be a denial of service attack, but I 
think this obvious and not really interesting. What is more interesting 
is that the unsigned parts can be altered. So instead of

> 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 for signed TLDs 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.
/In between note: This is not true, the unsigned parts can be altered/
> Thus, if there is a machine-in-the-middle attack on the priming query, 
> the results for a validating resolver for signed TLDs could be a 
> denial of service, or the attacker seeing queries while returning good 
> answers, but not the resolver's accepting the bad responses; however, 
> for unsigned TLDs, the attack would be successful.

I propose instead of this second paragraph, this text:

> A rogue root name server can view all queries from the resolver to the 
> root and alter all unsigned parts of responses, such as the parent 
> side NS RRsets and glue in referral responses. Resolvers following 
> referrals from a rogue root server, that do not explicitly query the 
> authoritative NS RRset at the apex of the child (TLD) zone and do not 
> explicitly query for the authoritative A and AAAA RRsets for those 
> child (TLD) NS RRsets, can subsequently be fooled into taking 
> addresses under the control of the attacker to be authoritative for 
> those delegations. With such resolvers (that do not do those explicit 
> follow up authoritative NS and address queries), an attacker that 
> controls a rogue root server effectively controls the entire domain 
> name space and can view all queries and alter all unsigned data 
> undetected (see also Section 3 of [draft-ietf-dnsop-ns-revalidation]).
>
> An attacker controlling a rogue root name server also has complete 
> control over all unsigned delegations, and over the entire domain name 
> space in case of non DNSSEC validating resolvers.
>
The third paragraph is fine I think.

-- Willem

Op 14-02-2024 om 19:25 schreef [e-mail]:
> Internet-Draft draft-ietf-dnsop-rfc8109bis-04.txt is now available. It is a
> work item of the Domain Name System Operations (DNSOP) WG of the IETF.
>
>     Title:   Initializing a DNS Resolver with Priming Queries
>     Authors: Peter Koch
>              Matt Larson
>              Paul Hoffman
>     Name:    draft-ietf-dnsop-rfc8109bis-04.txt
>     Pages:   11
>     Dates:   2024-02-14
>
> Abstract:
>
>     This document describes the queries that a DNS resolver should emit
>     to initialize its cache.  The result is that the resolver gets both a
>     current NS Resource Record Set (RRset) for the root zone and the
>     necessary address information for reaching the root servers.
>
>     This document, when published, obsoletes RFC 8109.  See Section 1.1
>     for the list of changes from RFC 8109.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8109bis-04
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-04
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop