At 12:51 PM -0500 1/9/09, Johnathan Nightingale wrote: >On 8-Jan-09, at 3:45 PM, Paul Hoffman wrote: > >>At 6:51 PM +0100 1/8/09, Jan Schejbal wrote: >>>As the MD5 algorithm is obviously not secure anymore, >> >>This statement is not based on reality, so the rest of the message does not >>follow. MD5 is not secure for applications that blindly sign inputs from >>non-trusted parties that can predict the content of the part of the message >>before the submitted text. This is an attack on the collision-resistance of >>the function. There have been no published practical attacks on the >>primage-resistance of MD5. > >No, but it's an algorithm against which attacks are already good enough that >we have to rely on peripheral CA practices like serial number selection in >order to be able to trust signatures.
Correct. >You're right, of course, that SHA-1 is heading that way as well, I never said that. The current best attack on SHA-1 is theoretical because of the number of steps involved, which is approximately as many as would be needed for MD5 before the attacks. Attacks always get better, but that doesn't mean that they get good enough to be practical. >and the decisions we make here will likely shape policy for SHA-1's eventual >decommissioning as well. That I agree with, although I believe NIST's decisions will be a lot more important. (Disclaimer: I sometimes consult for NIST.) >A key difference with MD5 is that its retirement is plausible, since CAs have >largely moved away from, or are presently moving away from issuing certs with >these signatures, so that retirement without breaking the internet is a >possibility. Do we know that is true? That is, has someone done a survey to be sure that the CAs that were issuing MD5 certs last month are no longer doing so? Please remember that they had the opportunity to just start randomizing their serial numbers (or to do nothing, for that matter...). >Obviously we need to actually have the ability to disable MD5, ideally any >algorithm, in the future. Nelson is working on that in bug 471539 as has been >mentioned. The real question for me is how we establish a timeline. A less-onerous alternative that completely solves the problem is to only disable MD5 validation in sub-CAs. This doe not penalize CAs in the trust anchor pile that self-signed with RSA-MD5 (there is no attack there), nor on any of the non-expired end-entity certificates that they have issued. If any CA has legitimate sub-CAs that they identified with RSA-MD5, those sub-CAs would need new certificates, but that is an operational issue for the CA, and would not affect certificate owners or relying parties. >In a recent discussion with the members of the CABForum this topic came up and >I said to them that the discussion in the mozilla community was still active >(clearly) but that I would encourage CAs not to count on MD5 support long >term, and that if I had to ballpark a timeline, I'd put it between 6-18 >months, based very largely on our confidence that doing so doesn't damage a >significant portion of the public web. Please see above. Stopping MD5 support is not needed until there is a preimage attack on MD5. What is needed is stopping support for rogue sub-CAs. (BTW, it is theoretically possible that a very rich and determined attacker could create a collision attack that produced a sub-CA that had a SHA-1 signature on its certificate, but there are no numbers on how much harder that would be than the current attacks.) >Figuring out that confidence level is another question. I'm working on a side >project here that I'll blog about shortly, but the net of it is that I'll have >a couple hundred thousand certs from the public internet to help us draw those >conclusions. For instance, here's the data from 3000 or so (hardly enough to >draw conclusions from): > > 2427 Signature Algorithm: sha1WithRSAEncryption > 553 Signature Algorithm: md5WithRSAEncryption > 4 Signature Algorithm: sha1WithRSA > 1 Signature Algorithm: sha256WithRSAEncryption > 1 Signature Algorithm: dsaWithSHA1 > >So: > > - Do the work to arm ourselves so that when we are confident pulling the > trigger, we can actually do so with minimal changes (in case it happens in a > point release, for instance) > - Establish our feelings around how much of the net we are comfortable > invalidating if we kill an algorithm > - Establish a timeline we think is compatible with that A different approach (one that I think is more constructive) is: - Mozilla changes its rules for CAs in the trust anchor pile to say that they must not issue certificates with RSA-MD5 starting on some date (it could even be this year), and to say that sub-CAs cannot have their identities assured by RSA-MD5. This is a retroactive change to its acceptance policy in the pile. - CAs in the pile are required to send Mozilla a letter saying that they comply with all Mozilla policies, including this one. - All CAs for which that letter has not been received by the date given in the new policy are removed from the pile. This puts the responsibility squarely where it belongs: on the CAs and on Mozilla's policy enforcement. No technical changes are needed, and it shows that Mozilla is willing to bring its policies up to date with modern security practice. It is also a test run for Mozilla updating its trust anchor policies in the future. Thoughts? --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
