Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Eric Rescorla <[e-mail]>]

On Wed, Mar 30, 2011 at 11:55 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> Martin Rex <[e-mail]> wrote:
>> >
>> > Maybe I'm dense at the moment, but I don't understand
>> > "the DANE data need not be DNSSEC secured".
>> >
>> > Without DNSSEC, you have a vulnerability, because you can not
>> > enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records
>> > for the mis-issued certs of his choice or DNS-spoof the absence
>> > of DANE records (and the absence of DANE records will be quite
>> > common for more than just a few days).
>>
>> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
>> if they aren't signed, since that just brings you back to where you were
>> without DANE. However, the DANE records can be set with fairly long
>> expiries (like HSTS), thus providing a partial firewall against comodo-type
>> problems.
>
> I still don't understand.

I don't disagree with you about the facts of the situation, merely about how
they should be interpreted..

Best
-Ekr

> As Bruce Schneier says "security must be evaluated not based
> on how it works, but on how it fails".
>
> DANE without DNSSEC is a vulnerability by itself, because it can
> be abused by an attacker to make things work that shouldn't work
> (the trust rooted to DNS case) and can create a false impression
> about security that is not provided (the cert/CA lock case).
>
> Verification of unsigned DANE TLSA records may cause a warm
> fuzzy feeling for some, but does not provide any security
> against a determined and powerful attacker.
>
> Commodogate may have been a government-backed hack.  The may be
> more such about which we don't know yet.  They could prevent OCSP-checks
> by making the relevant requests fail at the network layer.
> Similarly, they could prevent browser updates (with blacklists of
> the mis-issued certs) at the network level.  And they could spoof
> DNS replies as well.
>
>
> -Martin
>