On Mon, Feb 21, 2022 at 12:16 PM Matthias van de Meent <[email protected]> wrote:
> I _could_ currently implement an attack flow that uses BGP hijacking of > the IPs of the servers that my A-records point to to receive a certificate > using the HTTP verification methods, and get signed certificates at any of > the CA's indicated in my CAA records; assuming the CA does no further > verification than only what is required in the baseline requirements. We > can remove this attack vector completely by limiting the allowed > verification methods on my domain to only DNS Change (3.2.2.4.7), but this > would currently require specific support from the CA that I have defined in > my CAA record (I'm not sure there are CAs that do this). > Correct, there aren't, because it turns out this is tricky to define in a way that doesn't ossify the validation methods (e.g. how .18 and .19 were introduced). That's not to say some CAs aren't in favor of it, but it requires a strict level of discipline in the CABF, and that's never been one of the Forum's virtues. > Sure, this might also be implemented through CA account binding (or > something similar); but that means that each CA would need to implement > their own account binding system; which is not a scalable solution for > users, and introduces the same issues as the DNS account reset flow, but > now there's one more password that can be compromised. > Yes, this is generally where I lean to as a solution, because it allows a degree of method agility that can be negotiated out-of-band. It has the downside that it's not as strict as the CAA method of limiting validation methods, but that's actually the upside/virtue trying to be achieved. To the point of password compromise, though, it moves the risk model from the DNS Registrar/Registry to the CA, which allows for avenues like the Baseline Requirements (and/or NetSec) to set prescriptive requirements here around such flows. It's a trade-off, admittedly, between allowing users to select registrars that implement the desired level of security (e.g. WebAuthN bindings!), but provides a level of accountability at scale that would otherwise not exist. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG-duKCAKwdxqBXqPSUQVi89m-cT5jjgZF6XSWtdq%3Dnrw%40mail.gmail.com.
