I vote for Dave's language to be added to ietf-dkim-base.
Tony
Dave Crocker wrote:
> 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/
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
