In that case I would suggest that we make SHA256 a MUST support for
signature verifiers and a SHOULD for signature generators.
SHA-1 should probably also be a MUST for verifiers and a SHOULD for
signers.
As a practical matter folk are likely to want to do DKIM with hardware
acceleration that only supports SHA-1 for some time to come. I don't
think we can realistically mandate SHA-256 as a MUST.
If implementations are to be genuinely interoperable then something that
calls itself DKIM compliant must implement both hashes.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Monday, February 20, 2006 6:33 PM
To: Daniel Dreymann
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Supporting alternate algorithms
While I wouldn't quibble with anyone's position on whether
sha-1 is still ok, or whether sha-256 is interestingly
stronger, (not being qualified myself), I do think the place
from which DKIM ought to accept guidance is the saag.
The saag minutes [1] from Vancouver contain the following:
Security Area Response to Hash Function Breaks
Russ said we should "walk, not run." This is not a problem yet
but as attacks are improved it will become a problem. NIST held
a hash workshop. Conclusions from that workshop include a
reminder that SHA-1 will reach end-of-life for digital
signatures
by 2010. Also, we cannot expect any new standardized hash
functions before then. The security ADs have decided
that we need
to transition to sha-256 now. There will probably be a later
transition to something new after it is developed. So, we need
to become good at transitions as we have at least two.
Protocols with active WGs will be analyzed within those WGs;
others in SAAG.
Directives to WGs/Chairs:
Do analysis on every protocol in the WG by IETF 65
Start standards work on transition to sha-256, but plan for
future transitions.
So, I'd encourage folks who want to debate algorithm
specifics to do so on the saag list, where such discussion is
more appropriate and where there is more expertise available.
(And so the discussion can be repeated less often:-)
For DKIM, I think we ought to try to take action as per the
above, but, in the knowledge that things can, and do, change,
so the more agile we can be, as a group, and in terms of the
specs we write, the better.
If there's an argument that DKIM should not follow saag's
line on this, then that of course would be appropriate to
discuss, but I find it hard to see what's that different
about DKIM in this respect.
Stephen.
[1] http://www3.ietf.org/proceedings/05nov/saag.html
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html