[ietf-dkim] Suggested alternate algorithm specification language, for no

Folks,


> > DKIM's base spec already has a mechanism that supports alternate
> > algorithms.
> >
> > Are there any changes to the mechanism that anyone is suggesting?
> No, we're still on MUSTs and SHOULDs for which ones.
As I understand the current situation, there are only two candidate algorithms 
being discussed, SHA-1 and SHA-256.  There is also the question of an 
alternative to SHA-256.  The security community's assessment of a preferred 
longer-term choice is underway and will, someday, converge in some formal way.
Until then, we need language in the DKIM specification that a) deals with the 
concerns about SHA-1 at least by allowing specification of alternative 
algorithms, and b) cites at least one other "preferred" algorithm in some 
fashion.  Again, at the moment, I've only seen SHA-256 as the candidate.
We already have satisfied a), with the algorithm-choice mechanism.

As Ned's note this morning has reminded us all:  The key to interoperability is 
defining a core of requirements that everyone must satisfy.
(My unkind response to anyone suggesting that we not satisfy this basic 
requirement is that the IETF is the wrong forum for the work, and they need to 
move to some environment like OSI community had, since it enjoyed creating 
non-interoperable specifications.)
In the case of DKIM, I believe that specifying what a *validator* MUST support 
is all that is essential to ensure interoperability.
That is, if we say that a validator MUST support SHA-1 and SHA-256, we have 
solved the interoperability problem.  A signer that chooses any other algorithm 
risks non-interoperability.  They are free to go down that path, but they had 
better have some basis for the choice.
In other words, we are trying to juggle two different requirements: 
interoperability and security.  The problem is that the latter one is a bit 
fuzzy at the moment. *Better still is that this working group can't resolve it.*
As I say, defining what the validator MUST support solves our requirement to 
ensure an interoperable base.
If we say that a signer SHOULD use SHA-256, then I think we have solved the 
security-strength concerns, for the moment.
If the security community converges on a different preference, prior to our WG 
Last Call for the base, then we can plug in something other than SHA-256.  It's 
a minor change.
However I think the model for the spec language is clear:

   A validator MUST support {SHA-1, SHA-256}.

   A signer SHOULD use {SHA-256}.

We can, of course, add discussion about the trade-offs.  This might lead to the 
somewhat unusual alternative for signer language, along the lines of:
   A signer MAY use {SHA-1} for its lower overhead, in spite of potentially 
reduced security strength.  A signer SHOULD use {SHA-256} for its higher 
security strength.

Ok, folks.  What have I missed?

d/

--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html