[ietf-dkim] Issue 1386 and downgrade attacks

[Eric Allman]

(For some reason Charles didn't copy the group on his reply to my 
message, so I've included the entire thing even though I only have 
one comment.


--On February 27, 2007 1:16:05 PM +0000 Charles Lindsey 
<chl at clerew.man.ac.uk> wrote:

> On Mon, 26 Feb 2007 22:31:15 -0000, Eric Allman
> <eric+dkim at sendmail.org>  wrote:
>
>>         RA      RAB     RB
>> SN      N*      N*      N*
>> SA      A       A       X*
>> SAB     A       AB      B
>> SB      X*      B       B
>>
>> Of course N means that there is no signature to verify and X means
>> there   is a signature that cannot be validated.  Pragmatically X
>> and N have the   same semantics since -base says that an
>> unverifiable signature is   equivalent to no signature. "*" means
>> that the recipient will do an SSP   lookup, at least as we (well,
>> myself at least) currently envision   things.  Also, any signature
>> that R cannot verify is treated as the SN   case.
>>
>
>> CASE I: SIGNATURE ALGORITHM
>>
>> Scenario: S (the sender) starts signing using both A and B, and
>> publishes selectors for each (i.e., we move down in the chart from
>> SA to   SAB).  As the time goes on we move from left to right in
>> the chart: R   first checks using A, then can try either (and
>> presumably prefers B),   then refuses to use A any more.
>
> Stop right there!
>
> Go back to the time before R starts using B (i.e. we are in state
> SAB  + RA).
>
> That state may persist for some considerable time (>>days, if not
> quite  years), and that is the window of opportunity for the
> attacker.
>
> He constructs bogus messages signing them with B (who cares whether
> they  are valid or not?).
>
> R cannot check their validity, but he can recognise that B is a
> valid  algorithm for messages sent from S, and also that "S signs
> everything".  So, knowing that the problem is likely at his end, he
> allows the (bogus)  messages through.

Any R that allows a signature through that it can't verify just 
because there is a DKIM-Signature header field in the message 
deserves everything it gets.  I'm not interested in adjusting the 
protocols to make life easier on outrageously stupid implementations.

I guess I need to add a new assumption to my analysis:

ASSUMPTION 5: Whoever implements the verifier at R must actually 
implement the specification as written.

> The proposed solution is that the SSP should enable S to say "I
> sign  everything with both A and B". In that case, R can observe
> that an A  signature (which be could have verified) is absent, and
> so he knows it is  bogus.

eric