Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson <[e-mail]>]

On Fri, Nov 1, 2019 at 10:34 AM Eric Rescorla <[e-mail]> 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