| HN Mirror

CAA is just a DNS record that can be changed at any time, so there's no vendor lock-in.

CAs that implement CAA request that record and check whether they're permitted to issue the certificate; if they're not, they should refuse issuance.

1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record.

2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.

1) No, it is not necessary to have full control over your domain's DNS to obtain a certificate. There are various domain validation mechanisms. Having full control over the HTTP server (as mentioned in the article) would be sufficient, as would having access to certain email addresses associated with your domain.

2) I don't know why you're telling me this - it's not related to either your original post, or my reply. I'm quite aware that CAA is only really effective if it is mandatory (in fact I've mentioned it in a sibling comment a couple of hours ago).

notatoad 3566 days ago

>CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.

CAA seems like another good step that the browsers can demand after a CA fucks up - like google has mandated that some CAs publish Certificate Transparency logs after they've mis-issued a cert, they should also be requiring CAA on threat of being revoked from the browser's trust lists.

Yeah - in theory, but in reality the browsers are reluctant because of all the other sites that a CA has issued certs for - no browser wants to be singled out for blocking some other non-related sites.

ivanr 3566 days ago

For what it's worth, my impression is that CAA will be mandated by the CA/Browser forum at some point. But, indeed, that's the main weakness of CAA—it requires that substantially all CAs support it.

There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself.

Look no further than at some of the past transgressions browsers let CA's get away with.

ivanr 3566 days ago

Maybe, but there's no memory effect associated with CAA and you can change your configuration it any time. You're not actually locked in.

> with CAA and you can change your configuration it any time

so too could an attacker. If an attacker is able to set HPKP, then they could just as easily reconfigure CAA to a CA that issues them a cert for your domain.

The attack described in the article (web server compromise) would not necessarily give you access to the DNS of your domain (that's putting a lot of eggs in one basket).

It's certainly an effective defense-in-depth mechanism.

> It's certainly an effective defense-in-depth mechanism.

1) We've seen time and again that complexity is the enemy of security. Generally, the more moving parts, the more likely for another flaw. This is less defense-in-depth than it is added complexity. The attackers have time on their side to figure out where the next hole is.

2) The OP suggests that HPKP failed because of practical reasons (domain admins are scared to death of getting it wrong and bricking their site) - things like CAA only add to the complexity.

1) I don't see how it can possibly be worse than the status quo. CAs already rely on DNS for domain validation. This is just another DNS query, with the reply being a whitelist of permitted CAs, not a replacement for domain validation. If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA.

2) CAA was introduced in this discussion as a possible solution to the RansomPKP problem. It is not a requirement for HPKP and the only effect on HPKP it would have is to actually reduce the risk associated with that attack.

> CAs already rely on DNS for domain validation

Not all - only a subset of certs issued

> If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA.

because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself.

> actually reduce the risk associated with that attack

and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access