Re: [ietf-dkim] Core algorithm support/use, draft text v2

J>>    A validator MUST support {SHA-1, SHA-256}.
> >    A signer MUST support {SHA-1, SHA-26}.  A signer SHOULD use
> > {SHA-256} for its higher security strength. However a signer MAY use
> > {SHA-1}, such as for compatibility with an installed base, lower
> > computational cost, or easier implementation effort.
> I presume that the syntax {x, y} means "x and y".
yeah.  pseudo set notation.  don't giggle too much.  couldn't think of any other 
 way to designate it.  "x and y" would have been too simple and I wanted to 
imply that the list is subject to change.

> I have read the discussion on "implement" vs. "use".  A signer could
> follow the recommendation and use SHA-256 all the time; in that case why
> MUST it implement SHA-1? 
This was what Ned discussed:  An implementation could claim to be compliant, yet 
be unable to interoperate with the Sha-1 installed base.

 On the signing side, what's implemented makes
> a difference if an algorithm is being negotiated, but there is no
> negotiation here.
The required core set work without negotation.  Hence a new DKIM validator could 
work with a legacy DKIM signer.

> The word "However" in the next sentence makes it sound like SHA-1 is to
> be used as an alternative to SHA-256.  This would have to be the case if
> the motive is computational cost or implementation effort [is that
> really a consideration?].  But compatibility would be maximized by the
> inclusion of both signatures.
>
> I propose the following alternate text:
>
> Signers MUST use SHA-256.  A signer MAY additionally sign with SHA-1 for
> compatibility with an installed base or to provide lower computational
> cost for verifiers that wish to use it.
My own opinion is that double signing is overkill -- and maybe misleading -- for
this application. As I understand things, SHA-1 is, in fact, valid for use 
today. At the least, if sha-1 gives acceptable security, then sha-256 isn't 
needed. If it does NOT give acceptable security, then it should not be used.
So double signing gives compatibility without better strength, but with lots 
more overhead.  In other words, I do not see the upside of the double signature.

d/
--

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