On Fri, January 3, 2014 10:15 am, Kurt Roeckx wrote: > Hi, > > Microsoft has proposed to stop issueing new certificates using > SHA1 by 2016 in certificates. > > (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx). > > Mozilla also has a bug that even suggest to stop accepting some > new certificates in 3 months and stop accepting any in 2017. > https://bugzilla.mozilla.org/show_bug.cgi?id=942515 > > But it's unclear if this is really a policy or just what some > people think should happen. > > This seems to also recently have been discussed in the CA/Browser > forum, but I have a feeling not everybody sees the need for this. > https://cabforum.org/2013/12/19/2013-12-19-minutes/ > > I want to point out the that SHA1 is broken for what it is used in > certificates. SHA1 should have a collision resistance of about > 2^80 but the best known attack reduces this to about 2^60. In > 2012 it costs about 3M USD to break SHA-1, in 2015 this will only be > about 700K USD. See > https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
For certificates, the issue is not "simply" collision resistance but it's resistance against second preimage attacks. Weaknesses in collision resistance are scary, but they do not in and of themselves imply a weakness to second preimage attacks (only that it's "likely" "soonish") > > With a collision it's possible to create a rogue CA. See: > http://www.win.tue.nl/hashclash/rogue-ca/ This is not entirely accurate or true. The weaknesses in the hash algorithm - both known and unknown - are what has motivated root programs to require a minimum set of entropy before "attacker-controled" data to reduce the probability of second pre-image attacks. The attacks against MD5 worked because the issuing CAs used predictable serial numbers, which allowed the attackers to predict the certificate contents before it entered attacker controlled data, and thus allowed them to successfully exploit second-preimage weaknesses. Microsoft requires 64-bits of entropy to be in the serial number or in the subject name. Mozilla currently *recommends* 20-bits, by virtue of depending on the Baseline Requirements (section 9.6 of BR 1.1.6). Either of these add a confounding factor to known pre-image attacks that would make even the attacks against MD5 "difficult". > > This is only based on what is the best know attack currently > publicly known. There might be other attacks that we don't > know about yet even further reducing the cost, specialised > hardware and so on. > > This is just waiting to either happen or until someone finds out > that it did happen. This is significantly overstating the risks at present, both known and extrapolated. There's no question that we need to phase out SHA-1, and that's already listed as a consideration for Version 2.3 of the Mozilla policy - https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3 > > I would like to encourage everybody to start using SHA2 in > certificates as soon as possible, since that's clearly the > weakest part of the whole chain. This is again an overstatement. Don't forget that SHA-1 is used throughout the SSL/TLS handshake (as is MD5, for that matter). SHA-2 certificates will not work for a variety of clients - including those running XP pre-SP2 and pre-Gingerbread (IIRC) Android devices. It's something we can begin to transition, but it's both not an *immediate* threat nor is it the end of the world/security at present. I applaud Microsoft's move here, and hope to see Mozilla follow. If anything, Microsoft's move reflects their increasing commitment to see XP end-of-lifed and to no longer hold the security community back. Mozilla can and should consider a similar program, but even if *just* Microsoft did it, the very nature of Microsoft setting forward the program requirements will have trickle-down effects to all Mozilla users. > > This is more important that stopping to use 1024 RSA keys since > they still have a complexity of 2^80. But you really should > also stop using that. No, it's not more important, and hopefully I explained above why you've misunderstood the crypto-analysis and corresponding risks. > > Can someone please try to convince the CAB forum about the need > for this? The CA/B Forum is very much aware of it. However, having studied and understood the cryptoanalysis, it's a far less dire situation than you paint in this message. Thankfully. > > > Kurt > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
