Dave Crocker wrote:
- Lastly, DKIM needs to plan for sha-1 being retired (2010) and probably
for sha-256 being superseded by some new NIST-competition-winning
algorithm in the next 5+ years. So even if we start now with "only
sha-256", all of the above is still an issue down the road.
DKIM already permits specifying different algorithms.
If you are suggesting that it needs to do more than that, to anticipate
some requirement that might be imposed 5 years from now, please elaborate.
Its neither that vague, nor that frightening. NIST will end up
organising a competition for a new hash algorithm - they've nearly
said as much already. When that's done, the winner will be a FIPS and
will be the algorithm of choice. That's likely to take a few years,
but probably not 10, IMO.
The point is that when the DKIM RFC is about 2-3 years old, there'll
likely be a different preferred algorithm and we should (now) try to
make that transition as easy as we can, so long as it doesn't hold us
up too much. But, if we do a good job on the sha-1/sha-256 issue now,
I'd hope that should be enough.
As for SHA-1 vs. SHA-256: Dealing with both the current desire to use
sha-256 and maintain compatibility with pre-IETF, existing use of sha-1
is handled easily by having the specification state something like:
A signer SHOULD use sha-256.
A validator MUST support sha-256 and sha-1.
This permits pre-IETF signers to be validated by post-IETF implementations.
Whether to make the signing behavior a SHOULD or a MUST depends upon
whether the IETF version is permitted to maintain downward compatibility
with pre-IETF validators.
Given that the very limited purpose of DKIM, for assigning transit
accountability, and given that SHA-1 is a "concern" rather than being
outright "broken", the use of SHOULD seems reasonable.
A MUST probably also is inappropriate because it then makes it
impossible for the signer to choose some other algorithm that the signer
deems appropriate.
I'd be fine with that. Although it'd be a pity not to have a MUST
for the signer, but I guess some wording could handle that.
Equally, I'd also be fine with the MUST for sha-256, if that were
where the consensus lay. I guess the main argument for the MUST on
sha-256 would be to encourage moving away from sha-1 before there's
much wider DKIM deployment.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html