5 ms·

What does CAA protect against? Malicious/pwned CAs can issue certificates anyways. Unless browsers start enforcing CAA correctness, this doesn't seem to be very

What does CAA protect against? Malicious/pwned CAs can issue certificates anyways. Unless browsers start enforcing CAA correctness, this doesn't seem to be very useful. Browsers checking the CAA record seems like it would be an OCSP-like situation where browsers don't do the check to avoid a performance penalty, or softfail when they get no response.

kelnage 10y ago
I'm not sure it "protects" anything, per se - more of a formalisation that CAs should verify that the domain owner is the one making the request. I doubt browsers will ever check CAA, since it's even easier to tamper with than OCSP (since the majority of DNS requests are still over plain text).
tialaramex 10y ago
Take Facebook's experience last year as an example Facebook has this policy where all the facebook.com and fb.com certificates, including sub-domains, test sites, everything, have to go through a central security team. Obviously they can't reach out to every CA in the world and tell them about this policy and the millions like it at every company. So they came to agreement with a single CA, and only ever use that one CA who knows their rules. A company working with Facebook built some site, let's call it example.fb.com. They were responsible for it, so they controlled the content on the site. Some employee at the contractor wanted an SSL certificate, they'd heard of Let's Encrypt, so they just used Let's Encrypt to get themselves a certificate. Let's Encrypt checked their proof of control, it was fine, so it issued a certificate to the employee. Now, within 24hours that certificate was published to the Certificate Transparency system, and Facebook's security team monitors CT, so they saw there's this certificate for example.fb.com which is from this new Let's Encrypt service not their usual CA and they didn't ask for it. They, understandably, go straight to alert status - possible attack in progress. In that particular case it ends happily, the firm making example.fb.com confesses to what happened, that they didn't read the terms telling them to get certificates from Facebook security, the certificates are revoked, it's not Let's Encrypt's fault this happened, CT logs are proved to do the intended job... But CAA allows Facebook to tell everybody "Digicert is the only CA we want issuing for our names" and not have this whole panic in the first place. With CAA in place, Let's Encrypt would have told that employee "Issuing for this name is forbidden due to CAA" and then the employee would look that up on Google, realise they just violated Facebook's policy and reach out to Facebook Security. No sirens, maybe somebody gets a slap on the wrist, life goes on.

kelnage 10y ago

I'm not sure it "protects" anything, per se - more of a formalisation that CAs should verify that the domain owner is the one making the request. I doubt browsers will ever check CAA, since it's even easier to tamper with than OCSP (since the majority of DNS requests are still over plain text).

tialaramex 10y ago

Take Facebook's experience last year as an example Facebook has this policy where all the facebook.com and fb.com certificates, including sub-domains, test sites, everything, have to go through a central security team. Obviously they can't reach out to every CA in the world and tell them about this policy and the millions like it at every company. So they came to agreement with a single CA, and only ever use that one CA who knows their rules. A company working with Facebook built some site, let's call it example.fb.com. They were responsible for it, so they controlled the content on the site. Some employee at the contractor wanted an SSL certificate, they'd heard of Let's Encrypt, so they just used Let's Encrypt to get themselves a certificate. Let's Encrypt checked their proof of control, it was fine, so it issued a certificate to the employee. Now, within 24hours that certificate was published to the Certificate Transparency system, and Facebook's security team monitors CT, so they saw there's this certificate for example.fb.com which is from this new Let's Encrypt service not their usual CA and they didn't ask for it. They, understandably, go straight to alert status - possible attack in progress. In that particular case it ends happily, the firm making example.fb.com confesses to what happened, that they didn't read the terms telling them to get certificates from Facebook security, the certificates are revoked, it's not Let's Encrypt's fault this happened, CT logs are proved to do the intended job... But CAA allows Facebook to tell everybody "Digicert is the only CA we want issuing for our names" and not have this whole panic in the first place. With CAA in place, Let's Encrypt would have told that employee "Issuing for this name is forbidden due to CAA" and then the employee would look that up on Google, realise they just violated Facebook's policy and reach out to Facebook Security. No sirens, maybe somebody gets a slap on the wrist, life goes on.