(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(_dot_)man(_dot_)ac(_dot_)uk> wrote:
On Mon, 26 Feb 2007 22:31:15 -0000, Eric Allman
<eric+dkim(_at_)sendmail(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html