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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell > Sent: Monday, February 20, 2006 6:33 PM > To: Daniel Dreymann > Cc: [email protected] > 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
