Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Martin Rex <[e-mail]>]

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.

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