Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Eric Rescorla <[e-mail]>]

On Wed, Mar 30, 2011 at 8:18 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> 1. Protecting against CA mis-issue (as in CA/cert lock).
>>
>> In the first case, the idea would be that the relying party would go
>> through its ordinary validation logic and if that failed, would reject
>> the certificate. However, if the validation succeeded,
>> it would check DNS and if that check failed, would then reject the
>> certificate. Only if both checks succeeded would the certificate
>> be accepted. [0] The objective of this type of mechanism would be
>> simply to defend against unauthorized certificate issuance.
>> Note that in this case, the DANE data need not be DNSSEC secured,
>> because an attacker who tampers with it will solely be able to
>> cause a connection failure, and in many cases (TLS, SSH, etc.)
>> an attacker with those capabilities can tamper with
>> the A record and block the connection that way.
>
> 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.

-Ekr