Subject: Re: [ietf-dkim] Core algorithm support/use, draft text v2

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Mar 2006 23:45:15 -0500

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:

   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.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 11 Mar 2006 00:16:34 -0500

I agree with both ideas, especially anything that allows the victim of the
system, "verifiers" to gain more insight, intelligence and information about
the data it is receiving to help pre-empts abuse, optimize, scale and manage
the extra activity.

And for what its worth, this is the type of "mechanical" engineering that
keeps me interested.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Mar 2006 08:25:09 -0800

> 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. 

> signer always uses sha256, and can be suspicious if a sha256 sig isn't 

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