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

[Eric Rescorla <[e-mail]>]

On Fri, Feb 7, 2020 at 12:19 AM Brian Dickson <[e-mail]>
wrote:

>
>
> 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.
>

I don't think we're getting anywhere particularly useful here, so I'll
probably make this my last response unless something particularly new
emerges.

The ability of an attacker to compromise a given connection depends on (1)
the ability to intercept the wire traffic and (2) the ability to compromise
the TLS connection. A successful attack (as a general matter) requires both
of these abilities. Because there are a number of environments in which the
ability to intercept wire traffic is trivial (e.g., an open WiFi hotspot)
TLS is designed under the assumption that the attacker has ability (1), in
which case, the security rests on ability (2), which it might achieve in a
number of ways, with key compromise being one of them.

It is certainly true that defense in depth is a good thing and that
measures which strengthen the user's wire traffic against interception by
the attacker will generally increase security. However, it is neither the
case that DNSSEC validation is sufficient to guarantee this protection
(contra your statement above state above) nor that in the absence of DNSSEC
validation compromise of the user's data is a generally anticipated
consequence (as implied by the text in question). It is not sufficient
because (1) the attacker may be on-path, in which case it is irrelevant
whether the client is able to resolve the right IP address or (2) the
DNSSEC signing key is itself uncompromised [usually we just assume that
keys are secure, but given that the scenario you are positing for WebPKI
failure is key compromise, DNSSEC signing key compromise needs also to be
in scope]. It is not necessary because, as has been noted already, we
generally assume that the WebPKI provides a reasonable level of security on
its own, although, as Adam observes, nothing is perfect.

-Ekr


>