Barry Leiba <leiba(_at_)watson(_dot_)ibm(_dot_)com> writes:
This must
be done in a way to prevent bid-down attacks during transitions,
I believe that Mark also has a proposal on the table for how to deal
with bid-down attackes.
And actually, as I recall the discussion in Dallas it seems that even
Russ and EKR were not worried about this issue. The idea was that
it's down to the verifier to determine which algorithms it's willing
to accept, and the removal of a "stronger" signature only matters if
the verifier isn't willing to accept the remaining, "weaker" one. I
have no opinion on this; I'm just bringing it up to the mailing list
from the session in Dallas.
I think that's a fairly accurate statement of my position, yes.
also must be done in a way so the recipient can unambiguously determine
the order in which the signatures appeared.
The downside of this are MTA's that reorder headers, which they do
unless they know it's a trace header. Which they don't for DKIM
since it's new.
Someone else had suggested adding some sort of signature sequence
field, which, if we did that, could robustly identify the order, and
could make is clear which are missing. Something like this:
DKIM-Signature: seq=3,1,1; ...
DKIM-Signature: seq=2,2,2; ...
DKIM-Signature: seq=2,1,2; ...
DKIM-Signature: seq=1,1,1; ...
...where the numbers represent signer sequence, signature sequence for
this signer, number of signatures that this signer added. Mike is
right that we can already sign all the existing sigs when we add a new
one, so it's really only the ordering that we have to worry about.
Note that how effective this is depends on the attacks you are
concerned about on your hash function. If, for instance, there
is a preimage attack, then this doesn't help. I don't have
a useful opinion on how likely a preimage attack is.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html