On 25 Feb 2006, at 9:51 AM, Dave Crocker wrote:
What I keep in mind is not so much what things look like today,
but what
they might look like 2-4 years from now, when Moore's law and many
grad
students have had a few more shots at us.
What I am trying to keep in mind is specification language. What I
cannot tell from this thread, is what language is being proposed.
The present one, which I'll summarize as MUST accept SHA-1, and
SHOULD use SHA-256.
I think I'm going to agree with the majority of what Elliot Lear and
Steve Atkins have said, but put a different slant on it.
I find this all to be exactly why the above proposal is to me the
right thing. We're doing strong authentication, but for (often) weak
semantic purposes. The signer is taking all the risk. Remember, the
signature accepts responsibility for the message. It also means that
the signer accepts risk for the signature being hacked. If the signer
accepts the risks of using SHA-1 because of performance or whatever,
so be it. That's what SHOULD is for.
Of course, the secondary risk is that the receivers will get bogus
messages. But also of course, they can reject all SHA-1 sigs as
evidence of a bogus message ipso facto.
Here's the way I see it:
Le Chiffre: Before I kill you, Mr Bond, let me explain my plan to
you. Do you see that array of computers on cookie sheets? That
<dramatic pause> is a SHA-1 collision finder! <evil laugh>
Bond: What are you going to do with it? Subvert bets at Casino
Royale?
Le Chiffre: No, they're using SHA-256, which is beyond even my
powers to crack. This is -- much more subtle than that. <cackles>
I am going to forge millions of DKIM messages, send them to
people all over the world, and then the reputation of the Direct
Marketing Association -- will -- be -- NOTHING!
Bond: Oh. Well. That's different. Sign me up.
This is one of the reasons why many people are upset at a light-
haired Bond, and think new screenwriters are in order.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html