ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures

2006-04-04 10:28:27
Sorry, I think we're still talking past each other.

If we have two algorithms, Old and New, then there are three
kinds of signer and receiver, respectively: Old, New, and Both.
This gives us a 3-3 interop matrix, with four possibilities at
each cell:

NO      - receiver can't verify
Old     - receiver verifies with old algorithm
New     - receiver verifies with new algorithm
???     - see below

                               SIGNER
RECEIVER          Old          Both            New
Old               Old          Old             NO
Both              Old          ???             New      
New               NO           New             New

So, in the case of signers which only support the Old or New
algorithms, they will only sign with them and so there's no issue. The
attacker can of course remove either signature but that doesn't do any
good because it makes the message unverifiable. So, only the middle
column where the signer signs with both algorithms is interesting.

Similarly, if the receiver can only read either Old or New signatures,
then removing one of the signatures doesn't do any good--you can't
force him to do anything other than reject the message. So, this
leaves us with the only cell in this column being the one where
there is a switch-hitting signer and a switch-hitting receiver.
This only makes sense if (as you suggest) the attacker has some
way of modifying the message but retaining the validity of the
weaker signature.

The question then becomes whether this attack is important. As
I argued in the WG meeting, if a receiver is willing to accept
messages that are signed with only the Old algorithm (a necessary
condition for this attack) then they are also susceptible to
attack on messages from "Old" signers, of whom there will be
plenty. So, given that, I'm not sure that it's particularly
interesting to provide receivers who aren't interested in
defending themselves against that attack to protect them
specifically against downgrade.

-Ekr







                  



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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