[ietf-dkim] Base issue: multiple linked signatures

[Jim Fenton]

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.
>
> One way this might be used is to have one signature that covers the 
> subject header and one that doesn't, to allow the verifier to detect a 
> subject change and decide whether it's OK.  As the spec is now, the 
> verifier would just find the one signature (that doesn't cover the 
> subject) that works, and use that, not considering the other.
I'm not sure where to jump in on the last week's discussion on this 
thread, so I'll go back to the beginning to add my two-cents worth.  My 
thoughts:

1. There is nothing in the base spec that precludes multiple signatures 
from being used in this way, except for the requirement in Section 5.4 
that the From header field MUST be signed.  So it wouldn't be possible 
to detect a modification to the From header field in this way.  However, 
as many others have noted, multiple signatures are an expensive way to 
do this.

2. Providing a way to deal with header field modification was the 
original intent of the z= tag/value.  At the time this was proposed 
(prior to the formation of the WG), there was considerable concern about 
verifiers using z= to "correct" a modification; since the spec does not 
deal with presentation issues at all, there was no way to indicate this 
to the recipient.  Telling the verifier to replace header fields with 
the values from z= seemed heavy-handed, so instead we got the strong 
"diagnostic use only" language not to use the z= values for 
verification.  I would support some gentler language that permits use of 
z= in verification, with particular attention paid to ensuring that a 
new security vulnerability is not introduced.

3. All of this is a very incomplete solution to the message modification 
problem, since it doesn't address body modification.  We already have a 
way to tell if a modified body is the cause of a signature not 
verifying, because the bh= value won't have the correct hash.  My 
solution would be for the modifier to sign the message after 
modification.  The verifier might want to apply reputation, 
accreditation, or other things like local whitelists (all of which are 
out of scope here) to determine whether they "like" that modification 
based on who did the modifying.

-Jim