[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

[Jon Callas]

-----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-----