Ned Freed wrote:
The problem here isn't that someone could configure the use of some
random
signature algorithm and still remain compliant, but rather that
someone can
write an implementation which supports generation of neither SHA-1 nor
SHA-256
signatures and still be compliant. As such, I suggest making support
for SHA-256
on generation a MUST and SHA-1 a SHOULD. Both SHA-1 and SHA-256 need
to be
a MUST for verifiers.
As my colleague Jim Fenton is fond of saying, I am reticent to impose
restrictions on verifiers.
I'm sorry, but it is folly to think you have a choice in the matter. There has
to be at least one mandatory to implement mechanism to insure all
implementations can interoperate. The least we can get away with is a single
common mandatory to implement for both signers and verifiers. But I'm reluctant
to do things this way for a variety of reasons including, but not limited to,
the ability to leverage the installed SHA-1 base.
Another reason for having two mechanisms in there is that it insures some
minimal amount of testing of algorithm ability will occur. In my experience
untested mechanisms are often broken mechanisms.
The issue here is how much they wish to
trust SHA-1, and there's no need for the IETF to dictate to them on this
count, and there should be no need for us to update the document when we
want to pronounce SHA-1 dead. That to me therefore rates a MAY. Just
as Phil mentioned in another note, we're pretty close to a green field
here. Had it been otherwise I might consider a SHOULD.
As Dave pointed out previously, this discussion continues to confuse
implementation requirements with usage requirements. Nobody is saying that you
have to accept a message signed with SHA-1 now and forever. Rather, what's
being said is that due to huge existing base of optimized and accelerated SHA-1
support out there, those users who want to use SHA-1 should have some assurance
for the time being of their ability to do so.
In particular, a document that says "SHA-1 support MUST be implemented for
verification and SHOULD be an available option for signing" doesn't need to be
revised when we reach the point of wanting to say "SHA-1 MUST NOT be used to
sign messages any longer".
The question of whether or not it is actually OK to make such a change (as
opposed to it being essential) is trickier in that it depends on whether or not
you care about the long-term ability to verify DKIM in old messages. My
personal view is that DKIM is intended to be ephemeral and it is therefore OK
to make such a change. But I don't know if we really have consensus on this
view.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html