----- Original Message -----
From: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
To: "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_dot_)com>
Sent: Wednesday, February 22, 2006 2:59 AM
Subject: Re: [ietf-dkim] Supporting alternate algorithms
As my colleague Jim Fenton is fond of saying, I am reticent to impose
restrictions on verifiers. The issue here is how much they wish to
trust SHA-1, and there's no need for the IETF to dictate to them on this
count, and there should be no need for us to update the document when we
want to pronounce SHA-1 dead. That to me therefore rates a MAY. Just
as Phil mentioned in another note, we're pretty close to a green field
here. Had it been otherwise I might consider a SHOULD.
Green Fields ... full of mushrooms.
I think this ought to be part of the Migration Planning. The past research
we done in regards to login/authorization methods, suggest the experts think
SHA1 is good enough for the next X years but that is should it definitely be
part of your planning to switch to sha-256.
In my opinion, lets remove this thorn from the side now for the new
protocol. Make SHA1 and SHA-256 part of the default signing choices and
that both are required for DKIM support. The technical recommendation
"should" be:
You SHOULD use the highest protection you deem necessary for
the transaction.
The signer could choose to use SHA1 for less-valuable transactions and
SHA256 for others. Who knows? He might incorporate "enhanced security" into
his cost/business model.
If a wide spread SHA1 hack does come out, signers will be able to switch to
SHA-256 on a moments notice.
The key is to make sure verifiers are ready for both.
This resolves it IMO.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html