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