On Tue, Dec 11, 2018 at 10:27 AM Hector Martin 'marcan' via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> 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. > > I think it;s worth calling out that Let's Encrypt has implemented what appears to be a relatively simple mitigation: https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945 I am also interested to know if other CAs are considering this or other mitigations (e.g. multi-perspective validation) for this attack. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
