Even if it is not really an issue with LE client. I think it would be great if not only the CA check the CAA record. This could be done by the clients too. So they could warn is an CA issued an certificate that was not permitted by the dns. This could be reported by the iodef record to the site owner.
By the way is there any plan for LE to support IODEF record ?
What should happen if a website operator wants to change CA while its current certificate is still valid, without granting the “old” CA issuing “rights”?
From my point there would be two options:
a) Analog to key pining for the time of the transition he would still allow the old and new ca to issue an certificate and remove the old ca from dns record after he installed the new certificate.
b) Change the old CAA record and mark him as critical and add an flag that invalidates it for the CA but not for the browser. For example “;issuedBefore=” since this an invalid extension from the CA point is not allowed to issue an certificate while the browser only check if the CA is valid and this is true, so the old certificate will still be accepted.
Much like soft-failing OCSP, this would be great except when you actually need it: when there’s an active MitM on your network. What’s worse here is that for the vast majority of domains (i.e. all domains without DNSSEC, plus all scenarios where clients could not make use of DNSSEC) you wouldn’t even have a way to cryptographically verify the response (like you can verify that the OCSP response was signed by the CA issuing the certificate), so an attacker could not only block the CAA request, but they could actually just spoof the response to make it look like your domain permits issuance from a rogue CA.
Key pinning mechanisms are available for those who need them. Certificate Transparency allows you to monitor such attacks in near real-time. I don’t think the goal should be to add multiple methods for doing essentially the same thing, especially if there are obvious weaknesses.
Most of these two articles describing why revocation doesn’t work apply here in some way, so I’ll leave the links:
https://www.imperialviolet.org/2011/03/18/revocation.html
https://www.imperialviolet.org/2014/04/29/revocationagain.html
1 Like
There is one difference. That put further security to the place.
- The Browser can cache the CAA dns record according to its live time.
- There are two difference transport ways for the information.
This mean if you do not sit directly on the users gateway but on the other side. For example you can intercept each traffic that goes from an northern country that is isolated to the rest of the world you are required to do more work for also intercepting dns traffic to.
And with the same reason you can refuse hpkp since you can say these header can be removed by mitm attacker.
To make this as effective as HPKP, you would need similar cache lifetimes. That unusual in the DNS and since it's not designed for this use-case, the cached records will get flushed quite fast anyway for any number of reasons, unlike HPKP which is designed to stick around when users clear their cache and site preferences manually.
That's not wrong, but it still doesn't add anything that HPKP doesn't do, while only protecting you against a subset of attacks.
TOFU is quite a bit different from establishing trust whenever your DNS resolver decides to flush its cache. Preloading is possible too, at least if you ask a Chrome developer nicely. And again, if you're using HPKP-like lifetimes and want browsers to enforce those (i.e. maintain the cache) ... why not just use HPKP? Doesn't seem like it's worth the added complexity.
1 Like
If you’re basically requiring DNSSEC, why not go the DANE route? Why even bother with a CA at all?
Not a good idea unfortunately.
1 Like
https://tools.ietf.org/html/rfc6844
“Relying Applications MUST NOT use CAA records as part of certificate validation.”
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.