[ietf-dkim] Base issue: multiple linked signatures

[Paul Hoffman]

At 11:21 AM -0500 12/26/06, DKIM Chair wrote:
>In discussions with the IESG to sort through their "discuss" 
>comments, I had a talk with Lisa Dusseault, and she had one point 
>that I want to bring back to the mailing list:  I don't think we 
>considered, in our discussions of multiple signatures, multiple 
>*linked* signatures, which could work TOGETHER to convey 
>information, and the protocol doesn't allow that sort of thing.  The 
>way dkim-base is set up, I don't think this could easily be added as 
>an extension, and it'd be a significant change at this point. 
>Here's the concept:
>* Signer puts on two signatures (maybe as two header records, maybe 
>as one that contains two sigs).
>* One of the signatures has minimal scope, maybe signing only 
>"from:", with l=0.
>* The other signature covers as much of the message as possible... 
>most headers, all the boby.
>* The two signatures work together.  If one verifies and the other 
>doesn't, the verifier can consider what was changed in the message, 
>and possibly use that information to deal with mailing list 
>modifications or whatnot.

I also discussed this with Lisa, and came to a very different conclusion.

What is being proposed above is that an additional signature be 
generated and validated for every "important" header. That is a huge 
waste of energy, and it will cause massive unnecessary resource 
usage, particularly for recipients who don't care why a signature 
might not have validated.

If the concern is "accidental" breakage, Michael's point is exactly right:

At 8:36 AM -0800 12/26/06, Michael Thomas wrote:
>One can already do this by copying the relevant headers into the signature
>using z=. I already do this and it works just fine for mailing lists.

If the concern is "purposeful" breakage, encouraging signers to sign 
messages covering only the From header and none of the body is 
incredibly bad. Wayne is exactly right:

At 11:49 AM -0600 12/26/06, wayne wrote:
>Wouldn't signing just the 2822.From: header be close to useless since
>it could trivially be replayed on all forged email?  Even if you throw
>in things like the 2822.Message-ID:, and 2822.Date:, etc., you really
>have more "security" with the Habeas haiku.


--Paul Hoffman, Director
--Domain Assurance Council