ietf-dkim
[Top] [All Lists]

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

2007-02-26 04:09:21
On Sun, 25 Feb 2007 22:09:06 -0000, John Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

So now let's say I have a message that has at least one good
signature.  As far as I'm concerned, I'm done, it's verified.  If I
were to check the SSP, the most that could happen is a variation on
the "I sign nothing" scenario, if the SSP claims there's some set of
signature algorithms other than what I found.  That is not useful to
the receiver, other than perhaps to identify senders insufficiently
competent to publish consistent key and SSP records.

If the message has enough good signatures which match the From (whatever) header to meet whatever your local policy requires, then indeed you accept it; end of story; no need for SSP.

Or I have a message that didn't have any good signatures.  I can't
tell whether that was because it was unsigned, it had a good signature
that broke in transit, it had a good signature that I didn't know how
to verify, or it had a bogus signature applied by a bad guy.  So, as a
receiver, this is all the same situation, it's unsigned.  If you
believe that SSP can state "I sign everything", you might throw it
away if that's what the SSP says.  Otherwise, what?

Eh? If it was unsigned, you know that.
    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).

So, being "unsigned", you consult the SSP, which maybe tells you "we sign everything". You might then reject it regardless on that basis and thus lose some genuine message simply because you couldn't verify the algorithm in use; more likley, you would want to allow such cases through (whilst also persuading your local geeks to implement the new algorithm ASAP). But, in the example quoted (message signed only by unverifiable algorithm B) you would then accept the bogus message. But an SSP response of "we sign everything with both A and B" would allow you to accept genuine messages from that site (because you can veriffy algorithm A) but reject the bogus one.

How does a SSP list of signing algorithms provide any useful
information to a receiver?  Unless I'm missing something rather
fundamental, it doesn't.

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