On Fri, 2006-03-10 at 23:45 -0500, Barry Leiba wrote: > I didn't see any follow-up to this comment by Phill, and I think it > might be useful: > > > I believe that the best way to do this would be to introduce a signature > > counter so that the order of signing can be recovered even if a message > > has its headers reordered. > > This might also be a good answer to the issue of downgrade attacks > during a transition period. If, say, we have a tag "n=", and the value > is "i,j" (this is signature record "i" of "j"), then a sender might do this:
Any prior (and now broken) signature may have been subsequently stripped where this would now lead to suspicion. The numbering that you describe would need to pertain to just the same signing-domain. In the dkim- option draft, there was an alternative suggestion to use roles to help minimize the number of signatures present to guard against DoS attacks while being sure to retain the MSA role while discarding all be the last Mediator roles instead. Role assignment could include primary and secondary signature roles. > > DKIM-Signature: d=example.com; a=rsa-sha256; n=2,2 ...etc... > DKIM-Signature: d=example.com; a=rsa-sha1; n=1,2 ...etc... > > ...and a verifier can figure out whether signatures have been reordered > or stripped out. > > We have also talked about putting something in the key record to > indicate which algorithms must be used, so a verifier can see that the > signer always uses sha256, and can be suspicious if a sha256 sig isn't > there, but sha1 is. Yes, this would be the case with the use of the binary CERT RR which also doubles the space available for an otherwise extremely restricted label space with 2K bit keys. It would also makes sense to change the dividing label from _domainkeys to _dkim to conserve space as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
