On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote: > Is this new from the past discussion?
I think what's new is someone actually tried this, and found 5 CAs that are vulnerable and for which this attack works in practice. > https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ Looking back, this attack is also documented in the paper linked in that thread, but unfortunately it's not open access. I get the feeling this may be why that discussion didn't really proceed further in that thread. I certainly missed it. The paper does list the vulnerable CAs, which are: > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs > use the same MX email server mcmail1.mcr.colo.comodo.net > which uses the same caching DNS resolver. The results from our > cache overwriting methods indicates that the DNS resolver software > is New BIND 9.x with DNSSEC-validation. > • Thawte, GeoTrust, RapidSSL: use the same MX server and > resolution platform. > • StartCom4 > , StartSSL: both use the same email server and the > same DNS resolver. > • SwissSign: uses New BIND 9.x > I think we're at the stage where it's less about a call to abstract action, > and actually requires specific steps being taken, by CAs, to explore and > document solutions. Saying "push for DNSSEC" doesn't actually lead to > objective threat analysis' and their mitigations. My last paragraph was intended as two separate statements; DNSSEC solves this problem but we can't magically flip a switch and make everyone do that (heck, my own TLD's registrar still doesn't support it, and yes, I've been pestering them about it). Given that, I think CAs should be required to implement practical mitigations against this particular attack, and I'm hoping that by pointing this out we can start a discussion about what those mitigations should look like :-) As you've noted, Let's Encrypt seems to be leading on this front. It would be interesting to see if any other CAs can document their approach to mitigating this issue, if any. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
