ietf-dkim
[Top] [All Lists]

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

2007-02-28 07:14:12
On Tue, 27 Feb 2007 13:06:05 -0000, Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:

Charles Lindsey wrote:
[big snip describing use of Magic s/w]
And then you have sufficient
information to decide whether it had failed because your Magic software
was inadequate, or because it was a bogus signature from a spammer.
 Q.E.D.

Not quite. Whatever policy anyone publishes is public. Any spammer
can always replicate everything correctly with the exception of
the signature bits and thus create a message that appears to adhere
to policy but with a broken signature.

The spammer cannot produce a good signature. If you see a broken signature with algorithm B, and the SSP tells you that the sender always signs with B (and possibly others) and you do not see any signatures for those others, then you reject the message on the grounds that it appears to be signed by someone who did not have the proper key.

Seems to me that that's a *very* good reason to ignore the entire
FAILed signature and not to use any supposedly Magic s/w.

But a signature using an algorithm that you do not know how to verify is not "FAILED" in any meaningful sense of that word (whatever Base may say). So it is grounds for consulting the SSP to see whether the signer has provided for this situation (e.g. by always providing an additional signature with the older algorithm A).

What have I missed?

The distinction between a signature that you knew how to verify and which turned out to be broken, and a signature that you did not know how to verify.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>