On Fri, Nov 1, 2019 at 10:34 AM Eric Rescorla <[email protected]> wrote: > >> DNSSEC security is orthogonal to privacy, and is not a requirement FOR >> PRIVACY. >> > > I don't believe that that's correct in this case. The issue here is that > in order to provide confidentiality for the queries (in this case to the > authoritative) you need to authenticate the resolver. And that means > authentically learning the name of the resolver. So, for instance, if I go > the learn the NS for .com and the attacker gives me www.attacker.com, > then he can learn my queries. The name of the resolver can be authenticated > by DNSSEC or (less strongly) by having each query protected via secure > transport. > > Unfortunately (and I agree that this is unfortunate) the design for DNSSEC does not protect the NS record in the parent with a signature.
The secure delegation does provide a signed DS, which means the child domain's DNSKEY can be validated, which protects the data on the child zone. However, the NS record used for the delegation, being unsigned, means the attacker can still MITM traffic towards the child zone. The validity of the child zone's NS records is signed, as would the corresponding A records if the NS *name* found in the child zone is also in a DNSSEC signed zone. (There is still the possibility of what amounts to "name chaining", e.g. if the NS name of the zone serving the child zone's NS name, is itself in a third zone, etc.) Protecting against this MITM requires not only DNSSEC on the child, but potentially DNSSEC on other related zones. It also requires that the resolver obtain the NS record and related A/AAAA records from the child, and then validate the certificate at the name of the NS, using CA validation or TLSA validation. TLSA validation avoids interoperability issues on CA trust, and avoids potential circular dependencies. TLSA validation only requires the use of the single DNS root of trust. So yes, DNSSEC is necessary, but compared to current resolver implementations (which don't always fetch the child NS data and validate it), is not yet sufficient. Brian
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
