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(_dot_)bigbank(_dot_)com>,
BigBank Security <security(_at_)statements(_dot_)bigbank(_dot_)com>
To: John Doe <jdoe(_at_)(_dot_)(_dot_)(_dot_)>
Subject: Account alert
Sender: bot(_at_)example(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html