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

[Brian Dickson <[e-mail]>]

Top reply to keep it brief:
WebPKI requires online keys. It is a core part of TLS; encrypting something  with the private key is the critical security function of the handshake.
DNSSEC does not require online keys. This is due to the communication model of DNS: publication. Once published, DNSSEC doesn’t care how you obtain the records. The validation depends only on public keys.
(There are instances where on-the-fly DNSSEC signing is done, of course; the general practice for how that is done is with HSM.)

Zone signing is generally done offline, and in many cases is done with an HSM. Keys that aren’t online are by their nature protected from compromise.

Some TLS keys may be protected with similar mechanisms, but it is nowhere near the percentage of DNSSEC.

DNSSEC validation is complete protection against an attacker who is not on-path.

Brian

Sent from my iPhone

> On Feb 7, 2020, at 2:17 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> 
>> 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
> 
>>