I would strongly suggest that we make SHA-256 the MUST on the signer
side for interop and SHA-1 a MAY.
From a S&M (Should & Must) perspective it is not logical to have a
SHOULD on the signer side. If we are requiring all verifiers to support
SHA-256 there is no logical necessity for SHA-1 support.
In principle I could build a 'zero config' email signer/sender box that
hooks into the infrastructure via DNS SRV and acquires its crypto keys
through XKMS-ACC or similar. I would not want to support SHA1 on that
box if it means an unnecessary configuration parameter.
-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
Sent: Friday, February 24, 2006 3:57 PM
To: Hallam-Baker, Phillip; John R Levine; Eliot Lear
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "John R Levine" <johnl(_at_)iecc(_dot_)com>; "Eliot Lear"
<lear(_at_)cisco(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, February 24, 2006 2:52 PM
Subject: RE: [ietf-dkim] agenda item on upgrading hash algorithms?
The reason people are pushing for SHA-256 now is not
because there is
a probable imminent break. It is because we know just how long the
process of switching algorithms takes.
I agree.
I think that the consenus here is to:
1) Start the SHA-256 transition now, making it a MUST for
verifiers,
MUST/SHOULD for signers.
My only take here is that this MUST/SHOULD for signers will
always be tagged with a basic implementation question of
"well, which one should I use?"
So I think it should be carefully phrase to say:
SIGNERS "SHOULD" use the highest form of security first among the
choices currently available {SHA-1, SHA-256}. Although it is out
of the scope of this specification, an SIGNER "MAY" use a
VERIFIER lookup concept to determine the highest form of
security it offers.
This helps or resolves both issues and addresses the future,
especially the case if indeed when a method is hacked and
DKIM signer wishes to quickly migrate to a new method as
supported by the validators. In my view, it is almost
inevitiable, the signer will need to be a lot smarter than
the documentation calls for. i.e. find out more about the
host system it is about to send a "valuable" mail to.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html