Re: [ietf-dkim] Base issue: multiple linked signatures
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:",
* 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'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
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.
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
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.
NOTE WELL: This list operates according to