Re: [dane] Behavior in the face of no answer?

[Nicholas Weaver <[e-mail]>]

On May 4, 2012, at 4:29 AM, Andrew Sullivan wrote:

> On Thu, May 03, 2012 at 08:18:41PM -0700, Eric Rescorla wrote:
>> 
>> While I understand that these operational constraints, I'm having
>> trouble understanding what security benefit DANE offers if one behaves
>> as you suggest, since it seems the attacker can simply force you to
>> ignore any records that DANE provides.
> 
> As a client, you could be making a decision about what is more likely:
> 
>    1.  The attacker is able to undermine some CA.
> 
>    2.  The attacker is actually on-path and going to undermine my
>    connection.  

Since the attacker is often a government, its 1+2.  For a CA attack to be useful, you probably need 1+2, as without 2 you still need to be able to get the victim to go to your site which, even in the absence of DNSSEC, requires being an on-path attacker in most circumstances.

A CA attack without effectively 2 is useless.


This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists.  Because an attacker can block the CRL check, and the CRL check is NOT mandatory (they are unreliable enough that its not treated as a hard fail), CRLs are useless for blocking attackers.


> I imagine that, over time, the tolerance for the broken infrastructure
> will go down, and the fall-back decision will be less and less
> attractive.  But if the protocol says that once a client supports
> TLSA, any not-fully-modern DNS environment just means "no TLS", then
> we will be promulgating a standard that cannot be deployed.  We might
> as well not publish it.

DNSSEC at all requires client validation, and client validation REQUIRES that the client be able to bypass the significant-probability-broken recursive resolver already.  DANE doesn't really add to that:  If the client can fetch DNSSEC signed records, TLSA won't be a problem.