As the MD5 algorithm is obviously not secure anymore, MD5 signature support should be removed as soon as reasonably possible. Due to the high number of certificates currently around that would become invalid if MD5 was deactivated now, it is currently not realistic do do it immediately.
Instead, I would suggest announcing a fixed date at which MD5 signature support will be disabled in all mozilla products, regardless of how many certificates with such signatures will still be around at that time. This date should probably be something about 1 year + 2 months after the announcement to allow anyone who still issues MD5 certificates enough time to change that and then 1 year so most of the issued certificates are exchanged by new ones by then. For anybody who uses MD5-signed certificates with a validity >1 year, this would still be plenty of time to replace them.
Intermediate CA certificates with a long lifespan signed using the MD5 algorithm could be explicitly added to the cert store (and marked as trusted) until their expiration date. This way, only few users should be affected by the change.
In order to do a clean removal of MD5 in approximately one or two years without affecting many users, the announcement would have to be issued soon in order to give enough time for the old certs to expire. I think that not issuing such a final date could lead to many MD5 certs being issued (for example, by sub-CAs) and thus still in circulation whan MD5 will be broken even more, so a hurried removal of MD5 will then be unavoidable.
Jan
-- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers...
>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.
>MD5 signature support should be removed as soon as reasonably possible.
>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.
I assume that for a cryptographic hash function to be called "secure", it has to be BOTH preimage and collision-resistant (respectively secure for all the usual uses). Obviously, the collision resistance (respectively security in certain usual uses) is not given, so I call it not secure.
>> MD5 signature support should be removed >> as soon as reasonably possible.
>...and it goes down hill from there...
Sorry, I maybe did not make clear that it should be dropped for verifying certificate signatures as valid only. As was proven, the attack on MD5 in that case is a very realistic one. I hope you did read my explaination what I call "reasonably possible", which is more than a year to allow a soft switch. I was NOT calling to remove it immediately. If I missed something, please tell me what so I can learn from my mistakes.
Jan
-- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers...
>>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.
>I assume that for a cryptographic hash function to be called "secure", it has to be BOTH preimage and collision-resistant (respectively secure for all the usual uses). Obviously, the collision resistance (respectively security in certain usual uses) is not given, so I call it not secure.
With that definition, SHA-1 is also not secure: its collision resistance has be reduced from 2^80 to 2^60ish by similar attacks as for MD5.
Are you saying that we have to deactivate signature validation for certs signed with SHA-1 as well?
>>>MD5 signature support should be removed >>>as soon as reasonably possible.
>>...and it goes down hill from there...
>Sorry, I maybe did not make clear that it should be dropped for verifying certificate signatures as valid only.
That is the same as you said above.
>As was proven, the attack on MD5 in that case is a very realistic one.
Correct. But the attack is not what you described in this thread.
>I hope you did read my explaination what I call "reasonably possible", which is more than a year to allow a soft switch. I was NOT calling to remove it immediately.
True, but irrelevant. You did not describe the attack you were trying to avoid by deactivating MD5 signature validation. If you had described the attack based on the new findings, you would see that deactivating MD5 signature validation does not deal with the attack and needlessly harms all owners and relying parties.
> At 11:41 PM +0100 1/8/09, Jan Schejbal wrote: > With that definition, SHA-1 is also not secure: its collision resistance has be reduced from 2^80 to 2^60ish by similar attacks as for MD5.
Yes, the writing is on the wall for SHA-1 as well, and has been since 2005 or so.
> Are you saying that we have to deactivate signature validation for certs signed with SHA-1 as well?
In the same announcement, I would send a warning shot:
SHA1 will face the same fate within the next year or two. We don't know when, but we are also moving to phase out SHA1, and in future releases SHA1 certs may be rejected. No date set as yet, but be warned!
> 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. You're right, of course, that SHA-1 is heading that way as well, and the decisions we make here will likely shape policy for SHA-1's eventual decommissioning as well.
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.
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.
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.
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):
- 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
Please feel free to use "6-18 months" and "We should break less than 5% of SSL certs" as beating horses, if it helps.
Cheers,
Johnathan
--- Johnathan Nightingale Human Shield john...@mozilla.com
> - 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
Is it possible to disable the MD5 algorigthm for EV certificate chains sooner than for regular (DV) certificate chains? Or even disable SHA1 for EV chains and require SHA-256?
We would at least be increasing the trust factor for EV, if not the whole web.
Perhaps it would help if we had some additional information such as: what is the maximum certificate expiration time? That is, if all CAs stopped using MD5 *today* and switched to SHA-256, how long would it be before there were no unexpired certificates? Is that the upper bound on how long it would be before we could disable MD5 and SHA1?
> > - 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
> Benjamin Smedberg wrote: > Is it possible to disable the MD5 algorigthm for EV certificate chains > sooner than for regular (DV) certificate chains? Or even disable SHA1 for > EV > chains and require SHA-256?
MD5 is already not an option for EV SSL certs. The only place MD5 is permitted is in the (EV) root certificate, and (as has been written about recently on dev-tech-crypto) the trust anchor is protected by other means than its signature.
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):
> - 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.
> Perhaps it would help if we had some additional information such as: > what is > the maximum certificate expiration time? That is, if all CAs stopped > using > MD5 *today* and switched to SHA-256, how long would it be before > there were > no unexpired certificates? Is that the upper bound on how long it > would be > before we could disable MD5 and SHA1?
So as I mentioned, I've been collecting certificates for a little while, and soon I hope to make the code + data public but there are still some bugs to work out, and every crawl takes a day or so. Nevertheless, when I sort by year of expiration, across all currently- valid CA-signed certs I get:
This is from about 200k certs, whereas Netcraft typically reports about a million, and I've had CAs suggest they think the actual number is closer to 2 million. So this may represent 10-20% of the total secure web, maybe less, as a sample size.
Still, it's not nothing either, so if we don't mind extrapolating a bit: it seems to me that end of 2010, while further out than I'd like, is probably a good upper bound. At that point we'd have about 4000 valid, md5 certs out there we'd be breaking, out of my sample of 200k, roughly 2% (assuming none of them migrated in the interim).
Cheers,
J
--- Johnathan Nightingale Human Shield john...@mozilla.com
> On 9-Jan-09, at 1:27 PM, Benjamin Smedberg wrote: >> Perhaps it would help if we had some additional information such as: >> what is >> the maximum certificate expiration time? That is, if all CAs stopped >> using >> MD5 *today* and switched to SHA-256, how long would it be before there >> were >> no unexpired certificates? Is that the upper bound on how long it >> would be >> before we could disable MD5 and SHA1?
> So as I mentioned, I've been collecting certificates for a little while, > and soon I hope to make the code + data public but there are still some
Yeah, I was hoping for a "certificates always have a lifespan of {1,2,3} years" kind of answer, instead of a statistical one. Is there not a CA guideline for the maximum lifespan of a certificate?
> On 1/9/09 4:25 PM, Johnathan Nightingale wrote: >> On 9-Jan-09, at 1:27 PM, Benjamin Smedberg wrote: >>> Perhaps it would help if we had some additional information such as: >>> what is >>> the maximum certificate expiration time? That is, if all CAs stopped >>> using >>> MD5 *today* and switched to SHA-256, how long would it be before there >>> were >>> no unexpired certificates? Is that the upper bound on how long it >>> would be >>> before we could disable MD5 and SHA1?
>> So as I mentioned, I've been collecting certificates for a little while, >> and soon I hope to make the code + data public but there are still some
> Yeah, I was hoping for a "certificates always have a lifespan of {1,2,3} > years" kind of answer, instead of a statistical one. Is there not a CA > guideline for the maximum lifespan of a certificate?
Anything beyond two ears should be discouraged, whereas I view anything beyond four years unacceptable. There is at least one CA which theoretically still can issue certs for ten years according to their CP/CPS and have done so in the past. Mozilla is completly aware of that btw.
> Still, it's not nothing either, so if we don't mind extrapolating a bit: > it seems to me that end of 2010, while further out than I'd like, is > probably a good upper bound. At that point we'd have about 4000 valid, > md5 certs out there we'd be breaking, out of my sample of 200k, roughly > 2% (assuming none of them migrated in the interim).
that's 2 entire years away. OK. How about stating:
the target date for RELEASE versions to fully reject MD5 in certificates is *end 2010*.
any distro that is not RELEASE, such as new products, developer versions, betas, etc will likely drop MD5 earlier, and probably this year.
>> 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.
You don't have to ditch SHA1, just be ready to do so, and tell everyone.
(Thanks to Julien who thanks Nelson, this looks easy.)
>> 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.)
Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make up its own mind about MDs, which are the simplest possible building block in all of crypto, then what hope is there?
> .... Please remember that they had the opportunity to just start randomizing their serial numbers (or to do nothing, for that matter...).
That's today's situation. The problem is that it is very difficult to analyse all the attack possibilities in the future that burst from more advanced work in MD5 collisions. Do surveys, etc, all take time.
As an economic result, the practical thing for the vendor is to totally get rid of MD5, because that reduces the attack surface.
As a consequence, CAs should do the same, even though they can cover today's attack with randomisation.
Yes, we break some eggs in this omelette because CAs will have to re-issue some certs [1] ... but last time we checked, that's what they did for a business!
>> 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.
Jonathon, can we take this to the decision point?
IMHO, here is why I and everyone on the net needs this decision: Chatter and noise is mostly meaningless. Complex decisions are also difficult to interpret. Only decisions are worthwhile being reported to other agents.
Right now there are CAs all around the world wondering what to do [1]. Switch to SHA1? randomise? Write long posts about how this doesn't apply to them? Keep quiet and hope nobody notices?
We know it is going to happen, so the easiest thing to do right now is to move to drop all MD5, everywhere. But, while there is confusion of possibilities, there are endless arguments about what particular thing should be done. And there is then a divergence of results ... wheel spinning.
We can sweep all this away with a decision.
(Later on a timeline, but once the decision has been made, at least the direction becomes clear. Timelines are implementation details...)
...
> - 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.
I would argue that is already covered in the policy, because it has a clause that says that CAs must follow the technical decisions of Mozilla. I don't think we want to get into the rabbit hole of documenting all those technicalities :)
(But certainly a non-policy decision is called for.)
> - CAs in the pile are required to send Mozilla a letter saying that they comply with all Mozilla policies, including this one.
Sorry, what is the point of asking for them to say they will survive any switch-off?
> - All CAs for which that letter has not been received by the date given in the new policy are removed from the pile.
Sorry, what's the point of invalidating all the CA's certs, as opposed to just invalidating the MD5 certs?
> 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.
Well, maybe, but it also puts more weight on requiring the CAs to do business level steps such as getting the CEO to sign the letter, getting the auditor to agree, etc.
This is mostly a technical level thing that can in most cases be sorted out at a lower layer of communications; For most CAs, the technicians can turn off MD5 without any need to discuss it because they already have the framework in place.
This is what happened at Verisign, they were 1 month (apparently) away from dropping MD5 entirely, so they just advanced the timetable. No discussion needed.
iang
[1] to declare any conflicts: CAcert's current major ("audit fail") subroot has an MD5 signature. They are arguing what to do ... endlessly :(
>- 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),
Sure, that would be a great way to start with. I think that saying "do what you want but if you sign certs with MD5 your customers will be very unhappy because these certs will show up as invalid after 2010-xx-yy, so we suggest not issuing any after 2009-xx-yy" would be quite similar in effect, but would also have an effect on the CAs that are not trusted by default in NSS. (Of course, Mozilla has no obligation to keep those secure, but is there something speaking against it?)
The main difference is that my solution would force all MD5 certs out of circulation by the given date, no matter their expiration date, while yours would allow MD5 certs with long validity periods to stay in use. The question is closely related to whether we are reasonably sure that noone except the recent researchers managed to get a collision-signed cert or not. If we are willing to take that small risk (which is probably smaller than the unavoidable other risks like CA mistakes), and we don't care about CAs that are not trusted in the default settings, and we assume that preimage attacks on MD5 will not occur in the next years, then it is better just to disallow issuing new certs as you suggested and not invalidating old ones.
However, this is just my opinion, Ian G seems to have pretty good arguments why a purely technical decision (just dropping MD5 support after announcement) might be better.
No matter what way will be chosen, the sooner it happens, the sooner we will get rid of this security risk. (Mind that after the decision and announcement it will take 1 year or more until the MD5 problem is finally solved.) I think a "partial preimage attack" where you generate a "mostly" colliding cert and where it is possible to compensate for random serial numbers after the signature might be easier than a full preimage attack on normal certs.
Putting pressure on the CAs to act soon and do so in a secure manner (i.e. get rid of MD5 completely, more breaks are quite probable I think) is a good idea, IMO, so I suggest that the ones who can do the decision follow Paul's idea with a date like 3-6 months in the future(shoudn't be that hard to change the signature algorithm) and maybe follow up with mine to cover the remaining issues if it seems necessary after that. I think announcing to disable MD5 support in 1.5 years would also lessen the probability that a CA thinks "lets ignore their policy, they make an exception for us as we are too big to be removed".
Jan
-- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers...
>>That I agree with, although I believe NIST's decisions will be a lot more important. (Disclaimer: I sometimes consult for NIST.)
>Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make up its own mind about MDs, which are the simplest possible building block in all of crypto, then what hope is there?
Where did I say Mozilla didn't need to do its own analysis? I said that NIST's will be more important.
>>- 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.
>I would argue that is already covered in the policy, because it has a clause that says that CAs must follow the technical decisions of Mozilla. I don't think we want to get into the rabbit hole of documenting all those technicalities :)
That's absurd. You can't hold a CA to doing something that we don't document.
>>- CAs in the pile are required to send Mozilla a letter saying that they comply with all Mozilla policies, including this one.
>Sorry, what is the point of asking for them to say they will survive any switch-off?
They have actively signed an agreement that says they understand what we are demanding and will abide by it. This is no different than them applying to be in the trust anchor pile.
>>- All CAs for which that letter has not been received by the date given in the new policy are removed from the pile.
>Sorry, what's the point of invalidating all the CA's certs, as opposed to just invalidating the MD5 certs?
There is no reason to invalidate an end-entity cert that is signed with MD5. Doing so needlessly punishes end entities and relying parties and gains nothing in security. There *is* a reason to kick out CAs that do not follow Mozilla security and policy guidelines, of course: it's the same reason we would not have let them into the root pile in the first place.
>>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.
>Well, maybe, but it also puts more weight on requiring the CAs to do business level steps such as getting the CEO to sign the letter, getting the auditor to agree, etc.
Yes, that's what they are in the business to do.
>This is mostly a technical level thing that can in most cases be sorted out at a lower layer of communications; For most CAs, the technicians can turn off MD5 without any need to discuss it because they already have the framework in place.
We could not disagree more. This is a policy issue: is the CA willing to follow Mozilla policies in order to stay in the root pile. Further, even if a "technicians can turn off MD5", you are ignoring all the MD5-based certs that they have already issued for which there is no security threat.
>This is what happened at Verisign, they were 1 month (apparently) away from dropping MD5 entirely, so they just advanced the timetable. No discussion needed.
Please re-read the paper that described the attack. The authors discussed the attack with all of the named CAs. "No discussion needed" is just plain naive.
>The main difference is that my solution would force all MD5 certs out of circulation by the given date, no matter their expiration date,
...for no valid security reason...
> while yours would allow MD5 certs with long validity periods to stay in use.
...because there is no security problem with doing so.
>The question is closely related to whether we are reasonably sure that noone except the recent researchers managed to get a collision-signed cert or not. If we are willing to take that small risk (which is probably smaller than the unavoidable other risks like CA mistakes), and we don't care about CAs that are not trusted in the default settings, and we assume that preimage attacks on MD5 will not occur in the next years, then it is better just to disallow issuing new certs as you suggested and not invalidating old ones.
If you want to mistrust the cryptographer community so deeply, I'm not sure why you are even here. To date, not a single cryptographer of any stature has shown even a tiny bit of pre-image weakness in MD5 except for absurd scenarios (two messages that are millions of petabytes large). If you think you are smarter than they are, that's fine; I would prefer that Mozilla uses scientific research to make their decisions.
>No matter what way will be chosen, the sooner it happens, the sooner we will get rid of this security risk.
Please state your security risk, and in particular, say why the proposal I made (force CAs to agree not to issue new MD5 certs, and to not allow any sub-CAs signed with MD5) does not cover your desire.
>I think a "partial preimage attack" where you generate a "mostly" colliding cert and where it is possible to compensate for random serial numbers after the signature might be easier than a full preimage attack on normal certs.
If you can show that, I'm sure that the crypto community would *love* to see the paper. It would be a major advance from where we are today, even with literally thousands of researchers working on the same or closely-related problems.
> At 5:18 PM +0100 1/10/09, Ian G wrote: >>> That I agree with, although I believe NIST's decisions will be a lot more important. (Disclaimer: I sometimes consult for NIST.)
>> Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make up its own mind about MDs, which are the simplest possible building block in all of crypto, then what hope is there?
> Where did I say Mozilla didn't need to do its own analysis? I said that NIST's will be more important.
OK, point taken.
>>> - 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.
>> I would argue that is already covered in the policy, because it has a clause that says that CAs must follow the technical decisions of Mozilla. I don't think we want to get into the rabbit hole of documenting all those technicalities :)
> That's absurd. You can't hold a CA to doing something that we don't document.
Well, CAs aren't being "held" to anything, they are just advised that Mozo reserves the right to act unilaterally. Heavily stripped:
============ 4. We reserve the right ..., to discontinue including a particular CA certificate in our products, ...
[including] a CA certificate ... might cause technical problems with the operation of our software ... ============
It's in there. It is clear. The details can be discussed and argued about. And, whether Mozo should take this action, drastic or otherwise, is a completely separate question.
My point above is that they can, at least; and no change is required to the policy.
On your other points: OK! if I can summarise your argument, I see that it is this: that the potential of an attack and damages is exaggerated. To summarise my argument, it is too hard to economically figure out all the angles, so better to simplify.
> That's absurd. You can't hold a CA to doing something that we don't document.
Just a by-note on this one...It doesn't have to be in the CA Policy, but may be also in some by-laws or as we have it currently in the "problematic practices". This document is presented to every CA for a while already, so the CAs know about it, even if it's not part of the policy itself.
Perhaps a better mechanism regulating these aspects might be useful too.
>why the proposal I made (force CAs to agree not to issue new MD5 >certs, and to not allow any sub-CAs signed with MD5) does not cover >your desire.
I said that your proposal DOES (mostly) cover my desire and should be implemented. I also tried to point out the differences I see between the proposals and what conditions would (all) have to be met so it is not necessary to go the additional step of invalidating existing MD5 certificates.
I said that assuming that (1) there will be no preimage attack on MD5 for the next years (I did not make any assumptions on how probable that is, I don't consider it very probable that someone finds such an attack in the next few years) AND (2) if we are willing to take the small risk that someone might have already done (and not published but kept for later abuse) exactly the attack that was demonstrated at the end of the last year (which I considered OK), AND (3) we don't care about non-default CAs, then your proposal is way better than mine.
I already pointed out in my last post that (2) shouldn't be a problem but still wanted to point that risk out as something that is there and should be considered by people who can assess it better. I also did not consider (1) a problem (might not have been clear enough) and again just did not want to conceal that assumption. So it all depends on if we should care about CAs not trusted in the default install of Mozilla apps and thus bound by mozilla policies, and if we don't (which is reasonable) then I was and am saying that your solution IS better. In case we want to care about CAs that are not bound by mozilla policies (which I also consider reasonable), then (and only then) my proposal might have advantages.
I don't know why this makes you assume that I
> mistrust the cryptographer community so deeply >> No matter what way will be chosen, the sooner >> it happens, the sooner we will get rid of this >> security risk.
> Please state your security risk,
CAs that may still be issuing MD5 certs if *nothing* gets done. This is why the proposal you made *does* cover my desire. Your proposal would put all the risks we know to be significant out of the way, while mine would also fix some smaller ones that can *probably* be ignored as insignificant (but we can't be 100% sure).
I think mine is a tiny bit more secure (mostly by avoiding the risk that someone might already have a colliding cert using the known attack and didn't publish it) at the expense of refusing some valid certs, while yours is probably still secure enough and avoids invalidating certs.
As I learned that in security, it is often attempted not to take any risks, not even quite far-fetched ones, I don't know if someone who takes the decisions will not prefer the "paranoid" way despite the disadvantages. I really do not know what choice is the right one, taking certain minor risks or avoiding them too at a certain cost.
To put it short and clean: I consider your proposal better than mine, but depending on what one wants to achieve, mine could have some advantages at the cost of (bigger) disadvantages.
Jan
-- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers...
I think it's also important to note that this attack could as easily be used to create end-entity certificates. It likely wouldn't be as huge of a security hole as creating a fake CA, but if we focus on CAs without realizing that there are other classes of attack thus enabled we're ultimately doing the users and ourselves a disservice.
This is one reason why I think KCM is a good idea. I'm trying to write up a proposal on a means of handling it within the certificate structure, as an optional capability.
On Sat, Jan 10, 2009 at 4:43 PM, Jan Schejbal <jan.schejbal_n...@gmx.de> wrote: >> why the proposal I made (force CAs to agree not to issue new MD5 certs, >> and to not allow any sub-CAs signed with MD5) does not cover your desire.
> I said that your proposal DOES (mostly) cover my desire and should be > implemented. I also tried to point out the differences I see between the > proposals and what conditions would (all) have to be met so it is not > necessary to go the additional step of invalidating existing MD5 > certificates.
> I said that assuming that (1) there will be no preimage attack on MD5 for > the next years (I did not make any assumptions on how probable that is, I > don't consider it very probable that someone finds such an attack in the > next few years) AND (2) if we are willing to take the small risk that > someone might have already done (and not published but kept for later abuse) > exactly the attack that was demonstrated at the end of the last year (which > I considered OK), AND (3) we don't care about non-default CAs, then your > proposal is way better than mine.
> I already pointed out in my last post that (2) shouldn't be a problem but > still wanted to point that risk out as something that is there and should be > considered by people who can assess it better. I also did not consider (1) a > problem (might not have been clear enough) and again just did not want to > conceal that assumption. So it all depends on if we should care about CAs > not trusted in the default install of Mozilla apps and thus bound by mozilla > policies, and if we don't (which is reasonable) then I was and am saying > that your solution IS better. In case we want to care about CAs that are not > bound by mozilla policies (which I also consider reasonable), then (and only > then) my proposal might have advantages.
> I don't know why this makes you assume that I
>> mistrust the cryptographer community so deeply
>>> No matter what way will be chosen, the sooner >>> it happens, the sooner we will get rid of this >>> security risk.
>> Please state your security risk,
> CAs that may still be issuing MD5 certs if *nothing* gets done. This is why > the proposal you made *does* cover my desire. Your proposal would put all > the risks we know to be significant out of the way, while mine would also > fix some smaller ones that can *probably* be ignored as insignificant (but > we can't be 100% sure).
> I think mine is a tiny bit more secure (mostly by avoiding the risk that > someone might already have a colliding cert using the known attack and > didn't publish it) at the expense of refusing some valid certs, while yours > is probably still secure enough and avoids invalidating certs.
> As I learned that in security, it is often attempted not to take any risks, > not even quite far-fetched ones, I don't know if someone who takes the > decisions will not prefer the "paranoid" way despite the disadvantages. I > really do not know what choice is the right one, taking certain minor risks > or avoiding them too at a certain cost.
> To put it short and clean: I consider your proposal better than mine, but > depending on what one wants to achieve, mine could have some advantages at > the cost of (bigger) disadvantages.
> Jan
> -- > Please avoid sending mails, use the group instead. > If you really need to send me an e-mail, mention "FROM NG" > in the subject line, otherwise my spam filter will delete your mail. > Sorry for the inconvenience, thank the spammers... > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-cry...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy, I apologize if I'm misinterpreting your response to Paul's last comment, but I think you are suggesting that Mozilla could "hold a CA to doing something" that is 'currently in the 'problematic practices'" wiki page, purely because that wiki page is a document that is (you allege) "presented to every CA for a while already".
If that is what you are saying, I disagree with you. The wiki page clearly says (capitalization mine)... - "POTENTIALLY problematic CA practices". - "we do NOT NECESSARILY consider them security risks". - "Some of these practices MAY be addressed in future versions of the policy".
If Mozilla want to "hold a CA to doing something", then IMHO the first step towards achieving this has to be to update the Mozilla CA Certificate Policy to explicitly cover that "something".
The wiki page discusses *possible* *future* policy only.
On Saturday 10 January 2009 20:10:35 Eddy Nigg wrote:
> On 01/10/2009 08:59 PM, Paul Hoffman: > > That's absurd. You can't hold a CA to doing something that we don't > > document.
> Just a by-note on this one...It doesn't have to be in the CA Policy, but > may be also in some by-laws or as we have it currently in the > "problematic practices". This document is presented to every CA for a > while already, so the CAs know about it, even if it's not part of the > policy itself.
> Perhaps a better mechanism regulating these aspects might be useful too.
-- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
> Eddy, I apologize if I'm misinterpreting your response to Paul's last comment, > but I think you are suggesting that Mozilla could "hold a CA to doing > something" that is 'currently in the 'problematic practices'" wiki page, > purely because that wiki page is a document that is (you allege) "presented > to every CA for a while already".
> If that is what you are saying, I disagree with you. The wiki page clearly > says (capitalization mine)... > - "POTENTIALLY problematic CA practices". > - "we do NOT NECESSARILY consider them security risks". > - "Some of these practices MAY be addressed in future versions of the > policy".
> If Mozilla want to "hold a CA to doing something", then IMHO the first step > towards achieving this has to be to update the Mozilla CA Certificate Policy > to explicitly cover that "something".
I absolutely agree with you and in my opinion this is what should be done - at least for some of those practices. However as I understand, not everything is every time clear so cut to make it a policy, hence there are problematic practices which are reviewed on a case-to-case basis for every CA individually. Confronting the CA with this page early on during the information gathering period makes the CA aware of potential problems during the process. This is what happened for a while now. I think that not every bit and byte must be listed in the policy, but by-laws may exists to assist the intend of the policy.
Instead I think the policy should mention that such by-laws may exists - as matter of fact section 4 deals with it more or less.
|
