On 10/12/10 11:21 AM, Murray S. Kucherawy wrote: > (Barry Leiba said:) >> -1; I like the wording that's there. > Concur; -1 on the change. I furthermore submit that we are compelled to > describe the known "attack", as that's precisely what we are supposed to > include in Security Considerations.
I'm somewhere in the middle; I don't agree with Hector and I don't like the wording that's there either. Let's consider what a Bad Actor might try to do and what the result might be. Suppose that a Bad Actor successfully inserted a second From header field in such a way that the user's MUA displayed it in place of the original, signed, From header field. If the added From header field is from a different domain than the SDID, then the advice in section 6.3 paragraph 5 applies: "If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader." (I'm seeing a problem with this wording now too, but I digress.) Presumably this applies to whatever From header field is going to be displayed. If the added From header field is from the same domain as the SDID, there's a different problem. Perhaps the message had an Author Signature and the attacker intended to masquerade as a different user in that domain. But since we don't use the local part to establish what is and isn't an Author Signature (i.e., we don't look at the local part of i=) that's not a problem that DKIM is designed to address. The problem isn't limited to From, I suspect. One attack that we had considered early on was the modification of Subject, since it is prominently displayed to the user. We don't require signing of Subject, but it is recommended in section 5.5. Suppose an attacker adds an additional Subject header field, like: Subject: Buy fake watches at fakewatch.example.com! Will some clients display the second subject line? I suspect some will. Do we need to recommend that signers also add a protective second subject: to their h= value? Or do we need to require that verifiers make sure that any header fields that are signed and aren't supposed to be duplicated, aren't? I'm not sure, but right now I'm leaning toward the latter. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html