Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Warren Kumari <[e-mail]>]

On Mar 30, 2011, at 11:55 PM, Martin Rex 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.
> 
> 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.

I suspect think that you are talking past each other, so I'm going to try provide scenarios (and also make sure I understand):

In Eric's Case / Objective 1 (where DNSSEC might not be needed):
Scenario 1: If I am the operator of example.com and Mallory manages to trick EzCerts into issuing him a cert for example.com.
Let's say that Mallory is powerful, and can monkey with DNS traffic for users behind ISP Foo (and only behind ISP Foo).  If we allow TLSA without DNSSEC to say "Cert X must appear in the path" Malloy can do bad things to users of ISP Foo (by stripping the record, changing it to his, etc). BUT all users NOT behind ISP Foo (and all users of ISP Foo who do DNSSEC validation) will know not to accept Mallory's cert for example.com.   As the operator of example.com, I am unhappy, but I have at least limited the scope of the attack....

Scenario 2: I am the operator of example.com and Eve is has the ability to spoof DNS. She wants to cause a DoS against example.com, so she inserts a "false" TLSA record -- she does this so that users connecting though that path will fail the DANE check and be unable to connect.... This *is* a new DoS vulnerability, but if Eve is in a position to monkey with the DNS / inject DNS she *already* has the ability to cause a DoS by simply changing A / AAAA records, etc.

In both of these (and all the scenarios I can come up with), TLSA without DNSSEC validation doesn't make problems worse, but sometimes makes things better...

I think that Martin's concerns are all in Eric's Case / Objective 2, where DNSSEC *is* required...

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

Yes, but if we allow TLSA without DNSSEC *only for objective / case 1*, "they" can still attack victims for whom they can spoof DNS replies, but at least everyone else if better protected. Obviously TLSA with DNSSEC is far better, but allowing it without does have some benefits (and can be deployed much faster).


W

> 
> 
> -Martin
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure
>