Re: [ietf-dkim] Re: "I sign everything" yes/no

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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html