Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Martin Rex <[e-mail]>]

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


>
> 2. Allowing TLS to work without getting a certificate from one of the
>    established trust anchors.
>
>  [...]
>
> The draft to some extent conflates these two objectives, since it
> *both* injects a new trust anchor and restricts the list of potential
> certificates. It does not allow you to simply restrict
> the list of CAs/certificates without also injecting a new trust point.

Personally, I would also prefer if the information conveyed through
DANE would include a tag that clearly distinguishes "CA/cert lock" (for
a server cert issued under the traditional TLS X.509 PKI of browsers)
from a certificate path validation based solely on DNSSEC trust.

But ultimately, whoever gains control over the DNSSEC zone contents
will be able to preempt the validation under the traditional TLS X.509 PKI
for a server cert by supplying appropriately crafted DNSSEC-signed DANE
records.

Therefore, the existence of DANE will make DNS admins much more interesting
targets for attacks (as an alternative to attacking issuing procedures
of commercial CAs).


-Martin