Suggestion: Announce date for MD5 signature deactivation
Jan Schejbal
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...
Paul Hoffman
>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.
...and it goes down hill from there...
Jan Schejbal
>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.
Paul Hoffman
>>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.
Ian G
> 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!
iang
Ian G
> Yes, the writing is on the wall for SHA-1 as well, and has been since
> 2005 or so.
February 2005, here's my blog posts.
https://financialcryptography.com/mt/archives/000374.html
https://financialcryptography.com/mt/archives/000357.html
https://financialcryptography.com/mt/archives/000355.html
So pretty much all vendors should be happy with complete SHA2 coverage
by now. What's Mozilla's state?
iang
Johnathan Nightingale
> 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):
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
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
joh...@mozilla.com
Benjamin Smedberg
> - 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?
--BDS
Robin Alden
> On 1/9/09 12:51 PM, Johnathan Nightingale wrote:
>
> > - 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?
>
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.
Regards
Robin
Paul Hoffman
>On 8-Jan-09, at 3:45 PM, Paul Hoffman wrote:
>
>>At 6:51 PM +0100 1/8/09, Jan Schejbal wrote:
>>
>
>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
Julien R Pierre - Sun Microsystems
NSS / mozilla have supported SHA 2 algorithms for certificate signatures
for 5.5 years. Nelson implemented SHA-2 in NSS version 3.8, which was
released in April 2003 . See
http://www.mozilla.org/projects/security/pki/nss/ for the history, as
well as
http://www.mozilla.org/projects/security/pki/nss/nss-3.8/nss-3.8-release-notes.html
Johnathan Nightingale
> 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:
108331 2009
75313 2010
9973 2011
2627 2012
8625 2013
240 2014
12 2015
35 2016
61 2017
83 2018
7 2019
If I restrict to just md5-based signatures, it comes down to:
19441 2009
5810 2010
1981 2011
643 2012
1410 2013
21 2014
(Note the obvious spikes at the 5yr mark.)
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
Benjamin Smedberg
> 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?
(Thanks for the statistics anyway!)
--BDS
Eddy Nigg
Benjamin, see
https://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates
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.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Ian G
> 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.
the target date may be brought forward on whim...
Just a thought...
iang
Ian G
>> 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 :(
Jan Schejbal
>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".
Paul Hoffman
>>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.
--Paul Hoffman
Paul Hoffman
...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.
Ian G
> 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:
http://www.mozilla.org/projects/security/certs/policy/
============
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.
iang
Eddy Nigg
>
> 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.
Jan Schejbal
>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.
Kyle Hamilton
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.
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Rob Stradling
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 Nigg
> 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.
Eddy Nigg
> 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.
>
Incidentally section 13 could be lumped together with those by-laws
since it's only a recommendation. But we've discussed already that this
(section 13) and other issues were a first take at defining a policy
whereas things changed and a better understanding exists today for
potential problems.
Rob Stradling
resource during the "information gathering period" that happens *before* a
Root Certificate is ever accepted by Mozilla.
But (reading back a few messages in this thread), the context of this
discussion is Paul's proposal of a "retroactive change to its (Mozilla's)
acceptance policy in the pile" in order to curtail the use of MD5 by CAs who
have *already* been accepted by Mozilla.
Are you saying that Mozilla could change the Potentially Problematic Practices
wiki page, and then use "non-compliance" to anything on that page as grounds
for pulling a previously approved Root Certificate from the trust pile?
--
Eddy Nigg
> Eddy, I agree that the Potentially Problematic Practices wiki page is a useful
> resource during the "information gathering period" that happens *before* a
> Root Certificate is ever accepted by Mozilla.
>
> But (reading back a few messages in this thread), the context of this
> discussion is Paul's proposal of a "retroactive change to its (Mozilla's)
> acceptance policy in the pile" in order to curtail the use of MD5 by CAs who
> have *already* been accepted by Mozilla.
>
> Are you saying that Mozilla could change the Potentially Problematic Practices
> wiki page, and then use "non-compliance" to anything on that page as grounds
> for pulling a previously approved Root Certificate from the trust pile?
>
In theory yes, however there is a way doing these kind of things. First
of all it really depends on the issue itself and the risks involved. If
there is an issue which warrants for such a measure, CAs must be updated
and given time to adjust. How much time is reasonable in this respect
depends - again on the risk, potential implementation difficulties and
perhaps how many CAs might be affected from such a measure.
Again, the Mozilla CA Policy allows for such measures at any time and
there is no expressed or implied statement which requires Mozilla to
make a certain issue policy first. For example, if MD5 would completly
break SSL/TLS, than such a measure could be reasonable. But than in this
case it's better dealt with in the software itself. At least that's how
I interpret the policy.
Other issues affecting only a specific CA will be most likely dealt with
the CA directly, that's my understanding how Frank handles it.
Kyle Hamilton
exactly what must be done.
Once a "potentially problematic practice" is shown to have moved from
"potential" to "actual", it is a problematic practice. Once that
happens, it must be addressed.
CAs fall into a class of security called "operational security". This
means, among other things, that their operations -- inputs, black-box
certification procedure, and outputs -- are subject to continual
attack. Once a viable attack has been exhibited, mitigations against
attack must be revisited with that attack in mind -- and if they are
insufficient, new mitigations must be applied retroactively. (If an
attack currently takes 8+ months to pull off, that just means that in
less than 2 years it's going to take on the order of 4 months, in less
than 2 years after that it's going to take on the order of 2 months,
and in less than 2 years after that it's going to take on the order of
1 month -- assuming that there's no change in the understanding of the
underlying mathematics. This is in keeping with the corollary to
Moore's Law, that processing power doubles every 18 months, which
lately seems to be maintained even in the face of heat problems
inherent with doubling the number of transistors on a die.)
Yes, this does mean that new requirements could require operational
changes in some/all roots, or risk de-acceptance. If a CA's
operations are not secure (due to input, processing, or output), how
can anyone put any trust in them?
-Kyle H
On Mon, Jan 12, 2009 at 5:07 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> Eddy, I agree that the Potentially Problematic Practices wiki page is a useful
> resource during the "information gathering period" that happens *before* a
> Root Certificate is ever accepted by Mozilla.
>
> But (reading back a few messages in this thread), the context of this
> discussion is Paul's proposal of a "retroactive change to its (Mozilla's)
> acceptance policy in the pile" in order to curtail the use of MD5 by CAs who
> have *already* been accepted by Mozilla.
>
> Are you saying that Mozilla could change the Potentially Problematic Practices
> wiki page, and then use "non-compliance" to anything on that page as grounds
> for pulling a previously approved Root Certificate from the trust pile?
>
> On Monday 12 January 2009 11:26:03 Eddy Nigg wrote:
> 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.
Rob Stradling
> I believe that this is not only exactly what he is saying, but also
> exactly what must be done.
>
> Once a "potentially problematic practice" is shown to have moved from
> "potential" to "actual", it is a problematic practice. Once that
> happens, it must be addressed.
I fully agree.
Right now, as I see it, we have...
1). "potential" - The "Potentially Problematic Practices" wiki page.
2). "actual" - The Mozilla CA Certificate Policy.
So when a problem "is shown to have moved from 'potential' to 'actual'",
surely the way to address it would be to update the Mozilla CA Certificate
Policy and require CAs to conform to the new version (or risk having their
Root(s) pulled) ?
Eddy Nigg
>
> Right now, as I see it, we have...
> 1). "potential" - The "Potentially Problematic Practices" wiki page.
> 2). "actual" - The Mozilla CA Certificate Policy.
>
> So when a problem "is shown to have moved from 'potential' to 'actual'",
> surely the way to address it would be to update the Mozilla CA Certificate
> Policy and require CAs to conform to the new version (or risk having their
> Root(s) pulled) ?
>
Should the fact that MD5 is viewed as insecure or insufficient for the
assigned purpose be especially listed in the Mozilla CA Policy? Should
every possible algorithm be listed there too? Does your CA policy and
practice statements list any algorithm you don't intend to use for the
same reasons? Or supposed Mozilla deems certain practices in relation to
RAs and/or intermediate CAs an unnecessary risk and problematic, does
this have to be explicitly stated in the Mozilla CA Policy? If yes, what
else must be stated there or is the intend of the policy clear enough?
Paul Hoffman
>On 01/12/2009 03:59 PM, Rob Stradling:
>>
>>Right now, as I see it, we have...
>>1). "potential" - The "Potentially Problematic Practices" wiki page.
>>2). "actual" - The Mozilla CA Certificate Policy.
>>
>>So when a problem "is shown to have moved from 'potential' to 'actual'",
>>surely the way to address it would be to update the Mozilla CA Certificate
>>Policy and require CAs to conform to the new version (or risk having their
>>Root(s) pulled) ?
>>
>
>Should the fact that MD5 is viewed as insecure or insufficient for the assigned purpose be especially listed in the Mozilla CA Policy?
No, because it is not true. What is true is that signing with MD5 is now considered to be insecure, and what Mozilla will do about it.
>Should every possible algorithm be listed there too?
Probably, yes. That is, every allowed signing algorithm should be listed; we obviously don't need a list of the non-allowed algorithms.
>Does your CA policy and practice statements list any algorithm you don't intend to use for the same reasons?
We should not be relying on CA's CPSs: we should be relying on our own view of what is good-enough security.
>Or supposed Mozilla deems certain practices in relation to RAs and/or intermediate CAs an unnecessary risk and problematic, does this have to be explicitly stated in the Mozilla CA Policy?
Yes.
> If yes, what else must be stated there or is the intend of the policy clear enough?
Everything that we know that some CAs might do wrong that is not acceptable to Mozilla should be listed there. As we discover new categories (in this case, "uses unsafe algorithm"), it should be added. That list is not going to be long, but it *will* be valuable.
--Paul Hoffman
Eddy Nigg
>
> No, because it is not true. What is true is that signing with MD5 is now considered to be insecure, and what Mozilla will do about it.
>
>> Should every possible algorithm be listed there too?
>
> Probably, yes. That is, every allowed signing algorithm should be listed; we obviously don't need a list of the non-allowed algorithms.
>
>> Does your CA policy and practice statements list any algorithm you don't intend to use for the same reasons?
>
> We should not be relying on CA's CPSs: we should be relying on our own view of what is good-enough security.
This was a question directed to Rob, not Mozilla :-)
>
>> Or supposed Mozilla deems certain practices in relation to RAs and/or intermediate CAs an unnecessary risk and problematic, does this have to be explicitly stated in the Mozilla CA Policy?
>
> Yes.
>
>> If yes, what else must be stated there or is the intend of the policy clear enough?
>
> Everything that we know that some CAs might do wrong that is not acceptable to Mozilla should be listed there. As we discover new categories (in this case, "uses unsafe algorithm"), it should be added. That list is not going to be long, but it *will* be valuable.
>
OK, I'm not sure if this is/was the intention of Frank and the
objectives of the Mozilla CA Policy.
Nevertheless I suggest to start the work for a possible change to the
policy in order to address those issues now. Changes have been made to
the policy within relative short time in order to address EV, it's
entirely possible to get it accomplished with reasonable effort and
useful time-frame.
Kyle Hamilton
> On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote:
>> I believe that this is not only exactly what he is saying, but also
>> exactly what must be done.
>>
>> Once a "potentially problematic practice" is shown to have moved from
>> "potential" to "actual", it is a problematic practice. Once that
>> happens, it must be addressed.
>
> I fully agree.
>
> 1). "potential" - The "Potentially Problematic Practices" wiki page.
> 2). "actual" - The Mozilla CA Certificate Policy.
>
> So when a problem "is shown to have moved from 'potential' to 'actual'",
> surely the way to address it would be to update the Mozilla CA Certificate
> Policy and require CAs to conform to the new version (or risk having their
> Root(s) pulled) ?
I am inclined to agree.
Investigating along these lines, what would the procedure be for
getting Mozilla to update the Certificate Policy with explicit
algorithm acceptance/deacceptance policies?
It would be helpful for everyone if a full list of the algorithms that
NSS supports were available somewhere. Since that list defines "every
possible algorithm" (as relates to NSS, anyway), there can also be
list of algorithms and key sizes which are considered "too weak" for
CAs.
This kind of list ("weak algorithms") could also be usefully embedded
in the NSS code, but reliably warning on exceptions would likely
require an API change. (Instead of returning an int-as-int, one
possible way to handle it might be returning a bitfield-as-int, with
one bit stating 'there's a warning, you need to get the description of
the warning by calling another API function'. This would be very much
like OpenSSL's get_last_error mechanism, or Winsock's
WSAGetLastError.) (Note to the devs: would this be enough of a reason
to make an API change, in addition to the change in semantics for
startup/shutdown required for multiple NSS clients in a single
process?)
The basis for the "Potentially Problematic Practices" document is to
determine things which MAY (depending on the threat model employed by
the CA and other mitigating factors in place) be determined to be
problematic with regards to any given CA.
Putting aside political arguments (and everything related to policy is
political), I think that this situation could perhaps be better fixed
simply by stating "you can create certificates using any algorithm you
want, but we're not going to allow your MD5-signed certificates to
verify with our software".
-Kyle H
Ian G
> On Mon, Jan 12, 2009 at 5:59 AM, Rob Stradling<rob.st...@comodo.com> wrote:
>> On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote:
>>> I believe that this is not only exactly what he is saying, but also
>>> exactly what must be done.
>>>
>>> Once a "potentially problematic practice" is shown to have moved from
>>> "potential" to "actual", it is a problematic practice. Once that
>>> happens, it must be addressed.
>> I fully agree.
>>
>> Right now, as I see it, we have...
>> 1). "potential" - The "Potentially Problematic Practices" wiki page.
>> 2). "actual" - The Mozilla CA Certificate Policy.
>>
>> So when a problem "is shown to have moved from 'potential' to 'actual'",
>> surely the way to address it would be to update the Mozilla CA Certificate
>> Policy and require CAs to conform to the new version (or risk having their
>> Root(s) pulled) ?
>
> I am inclined to agree.
In principle, yes. Which is to say, Problematic Practices aren't of any
weight, they are just hints as to what sticky questions a CA is going to
receive.
> Investigating along these lines, what would the procedure be for
> getting Mozilla to update the Certificate Policy with explicit
(Note freudian slip above, it's CA Policy... :)
> algorithm acceptance/deacceptance policies?
First figure out whether it is a good idea. I'm "-1" on that. This is
CA business, not Mozo business. It is what CPS/CPs are for.
Now, I for one do not disagree with the core frustration of the people
here. But, replacing the CPS/CP function of a CA is not a good idea.
To start telling the CA what hash functions to use is to change the PKI.
The CPS tells the relying party what it does, that's its job.
Reference, Chokhani:
===============
4.6.1. Key Pair Generation and Installation
Key pair generation and installation need to be considered for the
issuing CA, repositories, subject CAs, RAs, and subscribers. For
each of these types of entities, the following questions potentially
need to be answered:
...
5. What are the key sizes? Examples include a 1,024 bit RSA modulus
and a 1,024 bit DSA large prime.
===============
http://tools.ietf.org/html/rfc3647#section-4
Although it doesn't say it, it is hard to conclude otherwise.
> Putting aside political arguments (and everything related to policy is
> political), I think that this situation could perhaps be better fixed
> simply by stating "you can create certificates using any algorithm you
> want, but we're not going to allow your MD5-signed certificates to
> verify with our software".
Right. No change needed, just do it.
iang
Kyle Hamilton
tied, and the only way to get things done is to just make a change in
the code...
...how is the political structure helping the coders? Or anyone else?
-Kyle H
Eddy Nigg
> If things have deteriorated to the point where the political hands are
> tied, and the only way to get things done is to just make a change in
> the code...
>
> ...how is the political structure helping the coders? Or anyone else?
>
Errr...how do you govern aspects of Sub CAs and RAs if not policy or
by-laws wise? MD5 is an easy one which can be dealt with in the code,
but else...?
Ben Bucksch
> SHA-1 is heading that way as well, and the decisions we make here will
I think it's important to prepare now that we actually *can*
decommission SHA-1. This means:
* All popular browsers need to implement SHA-256 and maybe other secure
algos as well.
* Afterwards, CAs need to start issueing SHA-256 certs.
* Afterwards, browser needs to remove SHA-1 support.
Each step likely will take years (1-3). This means we need to rush into
this process now, if we believe SHA-1 will fall (as you said).
MD-5 is a rather clear-cut case in comparision (all browsers support
SHA-1, most CAs already issue SHA-1, only 14% certs use MD5, all CAs
moved to SHA-1 by now to my knowledge).
I propose to announce that we'll stop supporting MD5 in 3 months, and
ask website owners to get new certs.
Other people preferred a longer time period, so I'd suggest end of this
year. Plenty of time for website owners to react. But we need to
announce it some time now, and CAs ideally contact their customers (with
these 5% of MD5 certs with validity into 2010 and beyond) 3 months
before this date as well, if they haven't reacted yet at this time.
> - Establish our feelings around how much of the net we are comfortable
> invalidating if we kill an algorithm
More important for me is what we did to warn them.
Hopefully, all high traffic sites will then have reacted (and if some
are remaining, we can contact them), leading to a traffic percentage
much smaller than the cert percentage, which is already small.
Rob Stradling
> On 01/12/2009 09:20 PM, Paul Hoffman:
> > No, because it is not true. What is true is that signing with MD5 is now
> > considered to be insecure, and what Mozilla will do about it.
> >
> >> Should every possible algorithm be listed there too?
> >
> > Probably, yes. That is, every allowed signing algorithm should be listed;
> > we obviously don't need a list of the non-allowed algorithms.
> >
> >> Does your CA policy and practice statements list any algorithm you don't
> >> intend to use for the same reasons?
> >
> > We should not be relying on CA's CPSs: we should be relying on our own
> > view of what is good-enough security.
>
> This was a question directed to Rob, not Mozilla :-)
Eddy, I do think that the Mozilla CA Certificate Policy should cover
*all* "actual" problematic practices. In this particular case, I think that
a blacklist of unsupported/non-allowed/not-recommended algorithms and/or a
whitelist of supported/allowed/recommended algorithms would be very useful
information for the CAs.
If Mozilla ever does decide to pull a CA's Root for whatever reason, wouldn't
it be so much better if Mozilla could say to them...
"CA X, you have no excuse. You have clearly violated clause N of version
Y.Z of the Mozilla CA Certificate Policy, which you had previously agreed to
adhere to"
...rather than...
"CA X, you took your eyes off the ball. You really should have been
following all of the discussions on mozilla.dev.tech.crypto more closely and
assuming that any opinion expressed might become Mozilla's official policy at
any moment. And you really should have assumed that violating
any 'potentially problematic practice' could give us cause to pull your Root
at any time"
?
To put it simply: I would really like Mozilla's expectations of the CAs to be,
on an ongoing basis, 100% clear.
> >> Or supposed Mozilla deems certain practices in relation to RAs and/or
> >> intermediate CAs an unnecessary risk and problematic, does this have to
> >> be explicitly stated in the Mozilla CA Policy?
> >
> > Yes.
> >
> >> If yes, what else must be stated there or is the intend of the policy
> >> clear enough?
> >
> > Everything that we know that some CAs might do wrong that is not
> > acceptable to Mozilla should be listed there. As we discover new
> > categories (in this case, "uses unsafe algorithm"), it should be added.
> > That list is not going to be long, but it *will* be valuable.
>
> OK, I'm not sure if this is/was the intention of Frank and the
> objectives of the Mozilla CA Policy.
>
> Nevertheless I suggest to start the work for a possible change to the
> policy in order to address those issues now. Changes have been made to
> the policy within relative short time in order to address EV, it's
> entirely possible to get it accomplished with reasonable effort and
> useful time-frame.
--
Eddy Nigg
> Eddy, I do think that the Mozilla CA Certificate Policy should cover
> *all* "actual" problematic practices. In this particular case, I think that
> a blacklist of unsupported/non-allowed/not-recommended algorithms and/or a
> whitelist of supported/allowed/recommended algorithms would be very useful
> information for the CAs.
Useful yes, up to certain extend. If there is too much information in
the policy, it will start to be problematic. The policy shouldn't be
changed every here and now and I think this is the position Frank
represents too.
>
> If Mozilla ever does decide to pull a CA's Root for whatever reason, wouldn't
> it be so much better if Mozilla could say to them...
> "CA X, you have no excuse. You have clearly violated clause N of version
> Y.Z of the Mozilla CA Certificate Policy, which you had previously agreed to
> adhere to"
> ...rather than...
> "CA X, you took your eyes off the ball. You really should have been
> following all of the discussions on mozilla.dev.tech.crypto more closely and
> assuming that any opinion expressed might become Mozilla's official policy at
> any moment. And you really should have assumed that violating
> any 'potentially problematic practice' could give us cause to pull your Root
> at any time"
> ?
I simply don't think this is how it works. But to your last question,
the answer is yes, let me explain:
Before Mozilla yanks any root (which isn't something Mozilla does for
fun really), Mozilla will confront the CA with the concern and assumed
risk concerning the practice of the CA.
- Mozilla will give the CA reasonable time to address the concern -
where "reasonable" really depends on the severity and scope.
- The CA may have the opportunity to convenience Mozilla also otherwise.
- The CA should present its proposal about how it intends to address the
concern raised.
- Should the proposal be acceptable to Mozilla, Mozilla will follow its
implementation.
- Should the CA fail for whatever reason - by preference even - to
address the issue, Mozilla will propose a dead-line and remove the root
thereafter. A CA may clearly decide that it's not going to address the
concern of Mozilla and prefer to have the root removed. Or Mozilla may
change its mind after understanding the counter-argument of the CA.
Additionally, a concern and reason for potential removal doesn't have to
be listed in the problematic practices or other documents even. It might
be a concern which is very specific to a certain behavior of a specific
CA which doesn't require to have it addressed otherwise.
>
> To put it simply: I would really like Mozilla's expectations of the CAs to be,
> on an ongoing basis, 100% clear.
>
Yes, this can be handled however outside of the Mozilla Policy, similar
to the FAQs of Microsoft's Root Program for example. I suggest however
that potential by-law locations be published in the policy. Those
by-laws may be changed more frequently than the policy itself.
Which reminds me....we need to start re-confirmation of EV audit
statements soon to make sure they are up-to-date.
Ian G
> Before Mozilla yanks any root (which isn't something Mozilla does for
> fun really), Mozilla will confront the CA with the concern and assumed
> risk concerning the practice of the CA.
> - Mozilla will give the CA reasonable time to address the concern -
> where "reasonable" really depends on the severity and scope.
> - The CA may have the opportunity to convenience Mozilla also otherwise.
> - The CA should present its proposal about how it intends to address the
> concern raised.
> - Should the proposal be acceptable to Mozilla, Mozilla will follow its
> implementation.
> - Should the CA fail for whatever reason - by preference even - to
> address the issue, Mozilla will propose a dead-line and remove the root
> thereafter. A CA may clearly decide that it's not going to address the
> concern of Mozilla and prefer to have the root removed. Or Mozilla may
> change its mind after understanding the counter-argument of the CA.
Sorry, where is this documented? It looks unfamiliar and unworkable to me.
> Which reminds me....we need to start re-confirmation of EV audit
> statements soon to make sure they are up-to-date.
!
iang
Eddy Nigg
>
> Sorry, where is this documented? It looks unfamiliar and unworkable to me.
>
In which respect unworkable? Please explain.
Ian G
> On 01/13/2009 12:50 PM, Ian G:
>>
>> Sorry, where is this documented? It looks unfamiliar and unworkable to
>> me.
>>
>
> In which respect unworkable? Please explain.
Let's work from Mozo's documentation. Where is it? Otherwise we are
liable to get distracted...
If this is not a documented situation, Rob already explained it. Or,
have a look at my comments on "dropping the root is useless".
iang
Eddy Nigg
> Let's work from Mozo's documentation. Where is it? Otherwise we are
> liable to get distracted...
>
> If this is not a documented situation, Rob already explained it. Or,
> have a look at my comments on "dropping the root is useless".
>
This is not documented, this is how Frank handled it so far and what
we've been discussing here in the past. Ask Frank about it if he wants
to document it and how he thinks to handle such situation.
Paul Hoffman
>On 01/13/2009 10:15 AM, Rob Stradling:
>>Eddy, I do think that the Mozilla CA Certificate Policy should cover
>>*all* "actual" problematic practices. In this particular case, I think that
>>a blacklist of unsupported/non-allowed/not-recommended algorithms and/or a
>>whitelist of supported/allowed/recommended algorithms would be very useful
>>information for the CAs.
>
>Useful yes, up to certain extend. If there is too much information in the policy, it will start to be problematic.
For whom? Most CAs run businesses where written policies are the norm.
>The policy shouldn't be changed every here and now and I think this is the position Frank represents too.
Where did Frank say, or even hint, that?
>>If Mozilla ever does decide to pull a CA's Root for whatever reason, wouldn't
>>it be so much better if Mozilla could say to them...
>> "CA X, you have no excuse. You have clearly violated clause N of version
>>Y.Z of the Mozilla CA Certificate Policy, which you had previously agreed to
>>adhere to"
>>...rather than...
>> "CA X, you took your eyes off the ball. You really should have been
>>following all of the discussions on mozilla.dev.tech.crypto more closely and
>>assuming that any opinion expressed might become Mozilla's official policy at
>>any moment. And you really should have assumed that violating
>>any 'potentially problematic practice' could give us cause to pull your Root
>>at any time"
>>?
>
>I simply don't think this is how it works.
Others disagree. The business model for most CAs are different than yours, it sounds like. This sounds like you want the pulling of a CA to be done informally, outside the realm of a formal policy. That's fine, but others may differ.
Eddy Nigg
>> Useful yes, up to certain extend. If there is too much information in the policy, it will start to be problematic.
>
> For whom?
For Mozilla mostly.
> Most CAs run businesses where written policies are the norm.
Mozilla is not a CA.
>
> Where did Frank say, or even hint, that?
Discussions here. Feel free to correct me (or even better Frank could
get involved a bit more to clarify a few things)
>
> Others disagree. The business model for most CAs are different than yours, it sounds like.
This is about the Mozilla CA Policy. It's not about CAs, I know what a
CA is, thank you!
> This sounds like you want the pulling of a CA to be done informally, outside the realm of a formal policy. That's fine, but others may differ.
Feel free to suggest and have it implemented otherwise. I was stating
the implemented informal approaches as I know them. It's all within the
realm of the formal policy, I did not suggest otherwise. I'm certain you
can't point me to anything else which would suggest otherwise either.
It's also what I think to be the correct approach. But you are free to
differ and propose a different approach (perhaps one which would pull a
root overnight without notifying the CA even).
Paul Hoffman
>On 01/13/2009 05:23 PM, Paul Hoffman:
>>>Useful yes, up to certain extend. If there is too much information in the policy, it will start to be problematic.
>>
>>For whom?
>
>For Mozilla mostly.
We disagree here. I think it would be more problematic for Mozilla to be accused of having hard-to-find policy changes than to simply change the policy itself when needed.
>>Most CAs run businesses where written policies are the norm.
>
>Mozilla is not a CA.
I never said it was. I was talking about Mozilla's partners in the trust anchor pile, all of whom are CAs.
>>Where did Frank say, or even hint, that?
>
>Discussions here. Feel free to correct me (or even better Frank could get involved a bit more to clarify a few things)
When you say that someone else said something, it is *your* responsibility to say where. "Here" is not a sufficient answer. Please point to a message. I say this because I have now (twice) re-read all of Frank's messages and I do not see him saying anything like you say he said.
>Feel free to suggest and have it implemented otherwise.
I have done so: Mozilla changes its inclusion policy, it informs everyone affected by the policy change, and gives them a period of time to start conforming. If a CA doesn't acknowledge that they conform, Mozilla pulls them from the trust anchor pile.
>I was stating the implemented informal approaches as I know them.
"Informal" is the operative word here. Many of us would prefer formal approaches.
>It's all within the realm of the formal policy,
... that says "we will do things informally".
>I did not suggest otherwise. I'm certain you can't point me to anything else which would suggest otherwise either.
Yes, I can. You said: "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."
>It's also what I think to be the correct approach. But you are free to differ and propose a different approach (perhaps one which would pull a root overnight without notifying the CA even).
I am suggesting exactly the opposite.
Eddy Nigg
>
> We disagree here. I think it would be more problematic for Mozilla to be accused of having hard-to-find policy changes than to simply change the policy itself when needed.
>
I did not suggest that there should be "hard-to-find policy changes" at
all. Besides that, I believe that not each and every issue can and must
be listed in the CA policy itself and neither do I believe that changes
to the policy itself are "simple" nor should they be done every while.
The policy clearly states:
We reserve the right to not include a particular CA certificate in our
software products, to *discontinue* including a particular CA
certificate in our products, or to *modify* the "trust bits" for a
particular CA certificate included in our products, at *any* time and
for *any* reason. This includes (but is not limited to) cases where we
believe that including a CA certificate (or setting its "trust bits" in
a particular way) would *cause undue risks* to users' security
There is no need for any policy change nor is it hard to find either.
>> Mozilla is not a CA.
>
> I never said it was. I was talking about Mozilla's partners in the trust anchor pile, all of whom are CAs.
And I was talking about the Mozilla CA Policy in my response to Rob upon
which YOU replied to me. In particular I said that not every allowed or
disallowed algorithm must be listed in the policy. And not each and
every practice (which may be a changing target anyway) which would
*cause undue risks* to users' security!
>
> I say this because I have now (twice) re-read all of Frank's messages and I do not see him saying anything like you say he said.
>
OK, if I can find the time for it I'll search for it.
>
> I have done so: Mozilla changes its inclusion policy, it informs everyone affected by the policy change, and gives them a period of time to start conforming. If a CA doesn't acknowledge that they conform, Mozilla pulls them from the trust anchor pile.
As such I'm the last person having a problem with it. The key is to
"inform" the CAs, it doesn't have to be in the policy per se.
>
> "Informal" is the operative word here. Many of us would prefer formal approaches.
I'm not sure if this serves Mozilla and the CAs best, but I have no
problem with it either, go ahead!
>
>> It's all within the realm of the formal policy,
>
> ... that says "we will do things informally".
No, please re-read section 4 of the Mozilla CA Policy.
>
> Yes, I can. You said: "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."
Indeed and I even repeated it just above again. This isn't informal at
all as section 4 clearly states. By-laws or other documents may assist
Mozilla and the CAs. They are not informal, specially not if the CA is
made aware of it.
> I am suggesting exactly the opposite.
Did you actually read what I wrote there?
Gervase Markham
> I propose to announce that we'll stop supporting MD5 in 3 months, and
> ask website owners to get new certs.
On the basis of any known risk?
The current attack requires the attacker to be able to get a cert signed
for a key they control. If all CAs stop using MD5 (which they should
have following this disclosure) then the attack mechanism is closed off.
I agree MD5 is unsafe and needs to be phased out, but given that there
is no current threat, we need to balance speed and inconvenience (both
to sites, and to users when they sites they want to visit stop working).
Gerv
Julien R Pierre - Sun Microsystems
Just because root CAs have stopped using MD5 doesn't mean every
intermediate CA in the world has stopped yet. It would be a fairly
arduous task to determine that. If a sub CA hasn't stopped using MD5
yet, they may be subject to the attack still today. And as the research
paper shows, the attack allows creating rogue certs that can be
backdated, so that there is no way to detect them at a future time.
IMO, we don't have complete confidence that every CA and sub CA has
closed the MD5 hole yet, and we can't be certain how long it will take
after the full details of the attack are disclosed for it to be replicated.
As a precaution, I think it makes sense to have a configuration option
for turning off all MD5 support today, and it also makes sense to be
prudent and set a date to unconditionally stop supporting MD5 at all. 3
months may be a short time, but the full details will be published very
soon, and the authors estimate that it would take about a month to
replicate their attack.
Paul Hoffman
>Just because root CAs have stopped using MD5 doesn't mean every intermediate CA in the world has stopped yet. It would be a fairly arduous task to determine that. If a sub CA hasn't stopped using MD5 yet, they may be subject to the attack still today.
Fully agree.
>And as the research paper shows, the attack allows creating rogue certs that can be backdated, so that there is no way to detect them at a future time.
Assume that we cannot detect rogue certs.
>IMO, we don't have complete confidence that every CA and sub CA has closed the MD5 hole yet,
Then we are failing at our job of policing our trust anchor repository. This is a much larger issue than whether a CA that we would want to remove anyway can be compromised by this attack.
We have rules for who is allowed in the repository. We can change those rules to say "must not sign with algorithms that use MD5". If someone breaks the rule, we remove them, and the threat is gone, without affecting the people who are safely using certs that were issued with MD5 when it was safe to do so.
Ian G
> At 5:29 PM -0800 1/13/09, Julien R Pierre - Sun Microsystems wrote:
>> IMO, we don't have complete confidence that every CA and sub CA has closed the MD5 hole yet,
What level of confidence do we seek?
Bearing in mind that complete confidence is a non-starter because we
have already set a lower standard as far as CAs are concerned.
Do we seek 90% of CAs and 90% of certs within those CAs? Perhaps a
published statement of awareness? Or their plan? Opinion by auditor?
Case-by-case basis?
> Then we are failing at our job of policing our trust anchor repository.
"Policing" is a very strong word ...
> This is a much larger issue than whether a CA that we would want to remove anyway can be compromised by this attack.
Indeed. The events of the last month have brought this issue to the
forefront.
It isn't about one CA. It's about Mozilla's role in this market and how
it relates its decisions to its mission, clients, CAs and other
stakeholders.
iang
Michael Ströder
> At 5:29 PM -0800 1/13/09, Julien R Pierre - Sun Microsystems wrote:
>> Just because root CAs have stopped using MD5 doesn't mean every
>> intermediate CA in the world has stopped yet. It would be a fairly
>> arduous task to determine that. If a sub CA hasn't stopped using
>> MD5 yet, they may be subject to the attack still today.
>
> Fully agree.
>
>> And as the research paper shows, the attack allows creating rogue
>> certs that can be backdated, so that there is no way to detect them
>> at a future time.
>
> Assume that we cannot detect rogue certs.
>
>> IMO, we don't have complete confidence that every CA and sub CA has
>> closed the MD5 hole yet,
>
> Then we are failing at our job of policing our trust anchor
> repository.
Yupp, and I think that's reality.
> This is a much larger issue than whether a CA that we would want to
> remove anyway can be compromised by this attack.
Yupp.
> We have rules for who is allowed in the repository. We can change
> those rules to say "must not sign with algorithms that use MD5". If
> someone breaks the rule, we remove them,
You have to know the sub-CA in question to remove the accompanying root
CA. Mozilla cannot know all of them. Sub-CAs are often not audited at
all. Sometimes not even the sub-CA's CP/CPS is reviewed by the root CA.
Anyway I'd also vote for a config option for turning off MD5 (like
turning off SSLv2 is possible and was made the default after a while).
Ciao, Michael.
Michael Ströder
> On 01/13/2009 10:15 AM, Rob Stradling:
>> Eddy, I do think that the Mozilla CA Certificate Policy should cover
>> *all* "actual" problematic practices. In this particular case, I
>> think that
>> a blacklist of unsupported/non-allowed/not-recommended algorithms
>> and/or a
>> whitelist of supported/allowed/recommended algorithms would be very
>> useful
>> information for the CAs.
>
> Useful yes, up to certain extend. If there is too much information in
> the policy, it will start to be problematic. The policy shouldn't be
> changed every here and now and I think this is the position Frank
> represents too.
Maybe it would be better to point to algorithm recommendations by NIST
or similar national organizations?
Ciao, Michael.