[ietf-dkim] Re: "I sign everything" yes/no
fenton at cisco.com
Fri Nov 24 22:25:27 PST 2006
Charles Lindsey wrote:
> On the contrary, it is the Sender header if present that should be the
> decider, and only the From if Sender is absent. People keep ignoring
> the fact that there can be several addresses in a From header (in
> which case Sender is obligatory).
It's not entirely forgotten; section 2.3 of draft-allman-dkim-ssp-02
discusses multiple From addresses. We thought about resolving the
ambiguity by (1) arbitrarily picking the first address in the From
header field, (2) picking the address in the Sender header field, or (3)
querying SSP for all addresses in the From header field, and combining
them somehow. We picked (1), because we don't know whether the MUA is
going to display the Sender address or not, and we felt that it is
likely that it will display the first From address regardless. But we
don't know how this will be displayed, and who the recipient is likely
to consider the author of the message, so it's very difficult to decide
the right thing to do. It's currently a very rare circumstance, so our
main priority here is to minimize the possibility that it becomes common
by virtue of becoming an SSP exploit, which we (the authors, not the WG)
felt favored (1).
> On top of that, the message might also be Resent, as Frank has pointed
> out. Hopefully, the resender will have preserved the Signature put
> there on behalf of the original Sender. If the Resender also "signs
> everything", then an extra signature should be picked up there.
There is a lot of question in my mind whether the fact that the resender
signs everything is relevant to the verifier. Since the Resent-From
header field is not very visible to recipients in my experience, an
attacker is just likely to pick a Resent-From domain that doesn't make
any SSP assertions.
> BTW, the bit in the base document that says the "From" MUST always be
> signed is wrong. It should have been the Sender, and maybe any
> Resent-From too. And that MUST is going to haunt us again when EAI
> happens, because both From and Sender may well get changed in transit.
> Not clear how EAI is going to get around that, but that obligatory
> From signing is not going to make that job any easier.
The language here was discussed and determined by WG consensus.
Personally, I favored the language in -base-03 and earlier that says,
"any header field that describes the role of the signer (for example,
the Sender or Resent-From header field if the signature is on behalf of
the corresponding address and that address is different from the From
address) MUST also be included." But that was not the WG consensus;
instead, it was decided that this was an aspect of how the signature is
used and interpreted rather than the validity of the signature itself.
More information about the ietf-dkim