Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Yoav Nir <[e-mail]>]

On Mar 31, 2011, at 11:15 AM, Richard L. Barnes wrote:

>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>> 
>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>> 
>> Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
>> you're directing the user to your own website with a dane rr matching public key.
> 
> You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

So it's really down to 4 cases:
- CA-lock (I only use Verisign)
- Cert-lock (I only use this cert)
- This CA (This is the CA cert that issues my certificate, and it may not be in your TAS)
- This Cert (this is the cert I'll be using, and I'm not promising that you can validate it)

While I see some value in cert-lock, I don't see much value in CA-lock. It would solve Comodogate if I was a customer of another CA, but not if I was a customer of Comodo.

Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.

So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

And yes, a certificate from a known CA can be appropriate for both use cases, and I expect that at least initially those would be more popular, as they work with "legacy" relying parties.