-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 25, 2007, at 10:46 AM, Michael Thomas wrote:
I just don't get this: if hash B is broken, isn't the right thing to
do is just kill off any selectors with hash B? Why do I need
policy when simply invalidating the selector would work even
better -- if it's still there, there's a pretty good chance that
somebody
won't invoke ssp and still be fooled after all. This isn't just about
attacks in the interim transition period is it? If a hash like, oh
say,
sha1 was suddenly catastrophically compromised you really wouldn't
have any choice but to move to the new algorithm.
Bingo. You win, Mike.
The main thing that people seem to forget is that DKIM is not a long-
term signature mechanism.
If I, the signer yank some set of keys (selectors, actually), then
the only downside to me is that there are messages in-flight that may
have no valid selector. I can fix this if I need to by changing my
sending policy at the same time.
The only fly in that ointment is TTLs on any DNS objects other people
have cached.
However, Phill has created a cute case that isn't *quite* a classic
downgrade attack, but is at least a kissing cousin of one. The
solution to it he proposes is that the policy language be rich enough
to say, "I always sign with A and B." If we want to be complete, the
policy statement could merely say, "I always sign with all of set S"
and if you only use one algorithm, then it trivially falls out of it.
Good suggestion, let's do it. End of story.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.3
Charset: US-ASCII
wj8DBQFF4etQsTedWZOD3gYRAqAQAKCKe9BSP7NxZQy1OPeJQyvyRTVPLACfdEpy
rvRUvEDfArnJKDmFr4GpQfc=
=BeX3
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html