ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

2010-10-12 19:31:52
  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

<Prev in Thread] Current Thread [Next in Thread>