Barry Leiba <[EMAIL PROTECTED]> 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
