[pfg]

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.

[jb613]

> 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

[pfg]

> Not all - only a subset of certs issued

I'm not sure I follow. My point is that if you're arguing that a DNS query is some kind of added complexity, then I have bad news for you, because DNS queries are already a part of all domain validation methods (whether it is email, HTTP, DNS, etc.)

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

This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process. It can help mitigate certain vulnerabilities in the domain validation process. For example, WoSign recently mis-issued certificates for github.com due to a bug in their domain validation system. If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued.

CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA. In addition to that, as has been mentioned in this thread, it might be useful in mitigating RansomPKP to a certain degree in the future.

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

No, you have not pointed that out. I have pointed out that you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain.

[jb613]

> I'm not sure I follow. My point is that if you're arguing that a DNS query is some kind of added complexity, then I have bad news for you, because DNS queries are already a part of all domain validation methods (whether it is email, HTTP, DNS, etc.)

We're talking about CA's issuing certs - DNS queries for email, http are outside of CA cert issuance.

> This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process.

The browsers need to decide when to trust a cert - and if/when CAA becomes involved in cert issuance, then I suggest this DOES have something to do with browsers. Furthermore, you're suggesting co-existence between CA's that check CAA and CA's that don't - which implies that either the browser or user has to make a determination of whether to trust.

But we're talking past each other. So using your example, think of it like this, how will you as a user know when you visit github that another WoSign hasn't happened? ...or rather - how would a LAYPERSON know they are secure? Github might detect it - but how do ordinary USERS?

> If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued.

that (wrongly) assumes ALL CA's trusted by EVERY browser will perform CAA check before issuing a cert for github.

> CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA.

The problem is not so much "fully-compromised CA" as it is we're trusting a whole pile of CA's and not all them behave the same.

> you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain

Any attacker that can gain access to web site admin credentials can also get the DNS credentials.

> CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases

You're using defense-in-depth again. Replace "-in-depth" with "-added-complexity". Here's a directly relevant example - HPKP arose from deficiencies in static pinning - which arose from deficiencies of CA/SSL ecosystem - which arose from deficiencies of plaintext traffic. It's not adding security "-in-depth" when all you're doing is resolving deficiencies in existing deployed solutions. The "depth" is single-level, not multiple.

[pfg]

> We're talking about CA's issuing certs - DNS queries for email, http are outside of CA cert issuance.

Still doesn't make any sense to me. Whether a CA performs a DNS query in order to do domain validation via email, http or to check a CAA record doesn't matter.

> The browsers need to decide when to trust a cert - and if/when CAA becomes involved in cert issuance, then I suggest this DOES have something to do with browsers.

The domains that a CA "vouches" for are part of the certificate. Browsers tell CAs how to determine domain ownership (by telling them to follow the Baseline Requirements). Implementing CAA means making the CAA check a mandatory component of these requirements. In other words, this would be just another step and if the domain appears on a certificate, the CA would indicate that the CAA check was successful. Browsers are the ones who would mandate this, yes, but there would be no other change necessary.

> Furthermore, you're suggesting co-existence between CA's that check CAA and CA's that don't - which implies that either the browser or user has to make a determination of whether to trust.

I'm not suggesting that. I'm suggesting making CAA mandatory. The scenario you're describing is the status quo, by the way: Some CAs implement CAA (Let's Encrypt, DigiCert); others (the majority) don't.

> But we're talking past each other. So using your example, think of it like this, how will you as a user know when you visit github that another WoSign hasn't happened? ...or rather - how would a LAYPERSON know they are secure? Github might detect it - but how do ordinary USERS?

Yes, we're talking past each other. My argument is that CAA would prevent certain mis-issuances, such as the GitHub/WoSign example. The certificate would not have been issued in my example. It is not a mechanism against a fully-compromised CA, as I have said before. That's what HPKP is for, as I have already said before.

> that (wrongly) assumes ALL CA's trusted by EVERY browser will perform CAA check before issuing a cert for github.

You're wrongly assuming that ALL CAs have the same domain validation vulnerability that WoSign had. I'm saying: Given the WoSign vulnerability, CAA would have probably prevented the mis-issuance.

Also: see previous comments regarding the effectiveness of CAA prior to it being mandatory.

> The problem is not so much "fully-compromised CA" as it is we're trusting a whole pile of CA's and not all them behave the same.

Which is why I have (for the n'th time) indicated that CAA is only fully effective if all CAs implement it (or in other words: if it becomes mandatory).

> Any attacker that can gain access to web site admin credentials can also get the DNS credentials.

What? RCE on the web server is not the same thing as full access to the DNS. You're not making any sense.

> You're using defense-in-depth again. Replace "-in-depth" with "-added-complexity".

Again, you fail to demonstrate how this complexity does more harm than good. You can make this argument for any change.

[jb613]

> Still doesn't make any sense to me. Whether a CA performs a DNS query in order to do domain validation via email, http or to check a CAA record doesn't matter.

Brush up on CA cert issuance. You seem to be assuming that all CA's perform similar levels of due diligence before issuing certs. They don't, they differ widely. Some go much further than simply DNS validation.

> I'm suggesting making CAA mandatory.

For practical reasons, I am skeptical this will happen. Too many paying entities. In the spec/contract, the MUSTs will be lowered to SHOULDs.

> The certificate would not have been issued in my example.

IF the CA checked the CAA...

> CAA would have probably prevented the mis-issuance.

Exactly - "probably".

> CAA is only fully effective if all CAs implement it (or in other words: if it becomes mandatory).

1) it won't happen. some CA's may/already-have implemented it but how is the browser/user to know which have and which haven't? 2) unclear that it is even fully effective

> Again, you fail to demonstrate how this complexity does more harm than good. art. Introducing a new mechanism requires demonstration that the added complexity is worth the effort. And in this case, it is clear that unless everyone implements it, there is no added benefit. Added cost without benefit is a bad start

[pfg]

> They don't, they differ widely. Some go much further than simply DNS validation.

You're missing my point. You're acting like adding yet another DNS query equals some massive increase in complexity. However, all certificate issuance requires DNS queries. I'm quite aware of other validation steps (like for OV and EV). These steps are performed on top of the domain validation steps I mentioned. I have never argued that those are the only steps.