[ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first
Author breaks email semantics
dotis at mail-abuse.org
Wed Jan 16 18:58:23 PST 2008
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
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
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!
More information about the ietf-dkim