-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On May 30, 2009, at 10:17 AM, Dave CROCKER wrote:
Folks,
In:
<http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html>
Steve Atkins posted a list of suggested DKIM features to drop.
This note is intended to anchor a discussion thread for discusses
one of those
features, namely:
Drop support for SHA1 entirely. It's beginning to look
cryptographically very dubious, and is being dropped by pretty much
everyone else. Even if the attacks against it don't affect the way
it's used in DKIM it seems unwise to suggest it be used at all. At
the
very least it seems a poor "marketing" move to include an algorithm
that's been dropped by most everyone else as insecure before this
spec
is finalized.
"Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.
Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa-
sha1." might provide enough wiggle room to allow existing code time
to
migrate away from SHA1.
I don't think it's worth expending breath on removing SHA1. Our power
to compel people to move away from SHA1 is limited. My belief is that
anyone who is still using SHA1 is suffering from a mild form of
insanity or is a sane person living in a slightly insane world. Even
if we remove it from the spec, the implementors will likely have to
keep it in for the slightly insane people and worlds.
It is far more important for us to put SHA3 into 4871bis, as that will
be finalized in 2012, and if you *can't* use it in DKIM, people would
be justifiably miffed for us.
In short, we shouldn't spend effort correcting the past that we can
better spend improving the future. This is especially true given that
improvements to the future are our best hope for correcting the past.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFKJFu0sTedWZOD3gYRArmmAKCRyh9UwaVR0wTp7SWJmn8mZhy8XQCgoA0F
AVv4u9eRsyqkkWaJNZDkSTA=
=6pwb
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html