Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson <[e-mail]>]

On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk <[e-mail]> wrote:
>
>>
>> but given that the recursive has no way of knowing what the
>> DNS client is planning to do (and that some ~20% of web traffic does not
>> use TLS), it's hard for me to argue that this document is making the wrong
>> recommendation about DNSSEC validation.
>>
>
> The question at hand is not about whether it ought to recommend DNSSEC
> validation but rather whether the text around that, which implies that
> failure to do so has a high risk of sending your sensitive *web* traffic to
> the attacker, is accurate given the high fraction of Web traffic that is
> protected with TLS and the likely even higher fraction of sensitive traffic
> that is.
>

The issue around implied risk, is a longitudinal one.

For sake of argument, let's assume 100.0% of web traffic is TLS protected.
Let's also assume that of the privacy resolver operators, there is at least
one that does not do DNSSEC.

If an attacker obtains the private key for *some* certificate for a web
site, what is the risk for the customers of the two groups of resolver
operators?

The risk for the DNSSEC validating operators' clients is zero if the web
site is in a DNSSEC signed domain.
The risk for the non-DNSSEC validating operators' clients is non-zero if
the web site is in a DNSSEC signed domain.

The risk depends on the ability of the attacker to poison the cache.
The validating resolver cannot be poisoned if the zone is signed.
The non-validating resolver can be poisoned even if the zone is signed.

The fact of non-DNSSEC validation is very likely known, particularly given
the public nature of privacy resolver operators, and trivial to confirm
directly by using them as a resolver.
The non-validating operators will definitely be a target for such an
attacker.

It doesn't particularly matter which certificate is compromised, in
principal; the question is whether the web traffic for that site can be
compromised. If the DNS poisoning succeeds, the answer is yes.

An attacker is unlikely to do the poisoning attack unless there is a
benefit to doing so, such as already possessing the private key.

I don't have any particular knowledge of how often keys leak.

I do have a pretty good idea how easy it is to poison a resolver.

It is generally only a factor of, at most, bandwidth and the ability to
send queries as a resolver client.
And unlike the typical ISP or enterprise or small network, the resolvers
here have to be open for use to anyone.
This makes them particularly vulnerable to the conditions that facilitate
poisoning.
And it is precisely this that make the case for a MUST rather than a SHOULD.

Brian