[ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

[Jim Fenton]

Arvel Hathcock wrote:
> The debate here is whether or not it's mission-critical for SSP to use 
> From: in all cases or whether some other sender identity (like Sender: 
> header) could be used to equal effect generally or in specific cases 
> (like when there are multiple addresses in From).
>
> Given that it would solve the problem described in 1525 and also bring 
> us closer to a consensus position perhaps this thread should discuss 
> what is lost through utilization of the Sender header in at least some 
> cases.
>
>
Good idea, Arvel.

Suppose that an attacker wanted to spoof a message from the domain 
statements.bigbank.com, a domain having a Strict Sender Signing Practice 
that is used for transactional email.  Attacker sends the following message:

Date: Wed, 16 Jan 2008 15:49:44 -0600
From: BigBank Statements <statements at statements.bigbank.com>, BigBank Security <security at statements.bigbank.com>
To: John Doe <jdoe at ...>
Subject: Account alert
Sender: bot at example.com



As currently composed, this message would not be SSP compliant because 
the SSP retrieved would be that of statements.bigbank.com (Strict) and 
the attacker would not have the ability to create a valid signature for 
that domain.

Now suppose that the Sender header field is used for the SSP lookup.  
Since example.com doesn't have an SSP record, it would be Unknown and 
this spoofed message would be SSP compliant.  Depending on the MUA being 
used, the recipient of the message is likely not to notice that there is 
a Sender: header field at all.

It has been argued that, since this working group (and perhaps all of 
IETF) doesn't have expertise in UI design, the MUA should not be 
considered at all.  While I agree that IETF probably shouldn't be 
designing user interfaces, I believe that it is entirely reasonable for 
us to make design decisions based on observation of the way that 
existing user interfaces do behave.  Not to do so results in protocols 
that are irrelevant because they don't solve real world problems.

-Jim