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 internet-dra...@ietf.org:
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
