ietf-dkim
[Top] [All Lists]

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

2007-02-27 05:56:00
On Mon, 26 Feb 2007 15:13:27 -0000, John Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

If it was signed with an algorithm you couldn't verify, you know that, If the signature was broken, you know that (but not why it was broken). All those situations are to be classified as 'unsigned' (but more detailed
information is available to you if you want to use it).

I would really like a security analysis of this paragraph.  In
particular, how do you tell a valid signature with an algorithm you
couldn't verify from a spammer's forged header that happens to look
like a signature?  You can't.  DKIM doesn't have signatures that
"almost" or "sort of" verify.  Either they verify or they don't.

If there was no signature present, then you consult the SSP of the From
(whatever) header to see if there should have been one.

Otherwise you have in front of you a signature, and its various tags tell
you that it uses

version dkim-2
algorithm rsa-sha-foo
canonicalization complicated/strained
signing-domain foo.example.com
retrieval machanism dns/funny
and, of course, the actual signature

and you have a Magic piece of software to which you give the whole thing.

Now IF the software knows how to use all of dkim-2, rsa, sha-foo,
complicated, strained and dns/funny, and IF it succeeds in obtaining a
public key for foo.example.com using dns/funny,
THEN it will verify the signature and report SUCCESS of FAIL (and maybe
the FAIL is PERM or TEMP).

But IF it does not know how to use all those things, or cannot obtain the
Public Key, then it is supposed to report FAIL.

BUT, if the Magic piece of software is Smart and Clever, it will tell you
that it failed because "I do not do sha-foo (or whatever)", or that the
format of the signature was clearly corrupted, or that the signature
failed, of that it failed but the body hash was correct. And so on.

If it reported SUCCESS (and if the signing domain matched the From header,
or whatever your policy required), then you accept the message.

But if it Reported FAIL, then you either bury your head in the sand and
reject the message regardless, or else you consider what the Magic
software actually told you, and in particular whether the failure might
have been because your Magic software was insufficient for the task, in
which case the message might well have been genuine after all.

So you consult the SSP for the signing domain to see whether the
combination of dkim-2, rsa, sha-foo, complicated, strained and dns/funny
could have come from that domain, and if so whether there should have been
a further signature which you ought to check. 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.



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