On 9/1/09 20:00, Paul Hoffman wrote:
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 :(
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
