I was reminded that Dave actually had suggested wording changes for two
places in the spec. I was referring to both.
Tony Hansen
[EMAIL PROTECTED]
Tony Hansen wrote:
> 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
