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

[Douglas Otis]

On Jan 16, 2008, at 4:54 PM, Jim Fenton wrote:

> 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.

As SSP is currently defined, the signature must be on-behalf-of the  
"first author"!  This should change to indicate that the "first  
author" domain establishes SSP and that compliance with SSP "strict"  
or "all" only requires a signature be by the "first author" domain.   
Compliance should not require a signature be on-behalf-of the "first  
author" via the i= parameter.  This is a mistake SSP is currently  
making.

Correcting this mistake would permit the "first author" domain to sign  
just the Sender header or even no header at all!  The MUA might  
display the From header, but because the "first author" domain had  
signed the message, the message MUST BE compliant with the "first  
author" domain's signing policies!!!!

One must assume the "first author" domain will control access to their  
outbound servers.  After all, the "first author" domain is who signs  
the message, and not the "first author" as you seem to suggest.  This  
might be true only with restricted keys.

> 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.

Yes, but you are adding a condition requiring signatures be on-behalf- 
of the "first author" even when they are not!.  While MUAs might be  
able to indicate a message has a valid/compliant DKIM signature, this  
information only conveys the message was introduced by the signing  
domain.  A message signed by DKIM says _nothing_ about the identity of  
the author.  The MUA might wish to highlight which entity the  
signature was on-behalf-of, but this gets rather complex when there  
are more than one signature involved.  The DKIM charter makes it clear  
this protocol is _not_ to identify the author.  DKIM is to _only_  
identify the domain.  Identifying the domain is plenty.

Instruct recipients to check the domain of the "first author" to know  
which domain established compliance.  Perhaps the compliant on-behalf- 
of header should be highlighted as well. Happy?

Your approach will cause valid messages signed on-behalf-of the Sender  
header to be rejected or require falsification of the on-behalf-of  
information.  Your approach requires something to be lost!

-Doug