Stephen Farrell wrote:
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.
Is there some reason that the DKIM working group needs to spend much effort
discussing the details of the preferred algorithm? I would think that that is
primarily a recommendation to be made by the security community.
The DKIM WG must to specify a choice of specific algorithms, of course, but the
design of DKIM and the specification of its mechanism for labeling its
algorithms is fully flexible. The spec document can plug in any algorithm that
the IETF security community recommends.
That is,
1. DKIM needs to have a mechanism that permits specifying alternative
algorithms. And it already does. So that requirement is already satisfied.
2. DKIM needs to specify a requirement for signer and validator support of a
core sets of algorithms, where a set may have a single member or multiple. It
already does, but clearly one or more of the sets need to be changed.
3. The DKIM working group needs to worry about things like cost of the
algorithms, availability of implementations for them, impact on backward
compatibility, transition, and so on. But I am failing to see why this group
needs to put energy into discussing the relative merits of different algorithm's
strength or lifespan.
4. On the matter of backward compatibility and transition, there has been some
recommended text. As nearly as I can tell, it did not get pursued or resolved.
No doubt, I am missing something fundamental that requires that we focus on the
level of detail that occurs every time a thread touches algorithm choice, but I
am not seeing what it is. Can someone explain how and why this is where we
should be putting our energy?
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html