Jon Callas wrote:
-----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.
But if it's a problem for TTL's on selectors, it's a problem for TTL's
on anything else too, including SSP records. I suspect getting wrapped
around the axle about the interim period of a catastrophic hash failure
is a good way to madness.
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.
Except for the fact that in order to know that, I'd have to do an SSP
lookup. But look at it this way: I have an authoritative source in the
selector as well as a proposed authoritative source in the SSP. They
are functionally the exact same information to the verifier. The
verifier already has to look up the selector; why would it be motivated
to look up SSP for the same information? Especially in the light of
the fact that -base and -ssp are and should be severable.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html