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