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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

DNS poisoning is used as an attack vector even with TLS where users can potentially ignore/accept fake certificates and lost $, for instance see https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/.

-Tiru

From: dns-privacy <[e-mail]> On Behalf Of Brian Dickson
Sent: Friday, February 7, 2020 1:49 PM
To: Eric Rescorla <[e-mail]>
Cc: Tim Wicinski <[e-mail]>; Adam Roach <[e-mail]>; Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail]; DNS Privacy Working Group <[e-mail]>; The IESG <[e-mail]>
Subject: Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)




CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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


On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk <[e-mail]<mailto:[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