On 10/12/10 12:01 PM, Dave CROCKER wrote:
On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote:
... 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.
We should keep in mind that DKIM's job is to deliver a validated
domain name. I believe none of the "attacks" that have been
discussed have anything to do with that task. Instead, they pertain
to other forms of attack on perceived message content validity, which
is entirely outside of DKIM's scope.
Disagree. DKIM is to provide an authenticated domain _associated_ with
message content, since the DKIM signature is _not_ visible to
recipients. As such, only the From header field is _required_ to be
covered by the DKIM signature and is used to select which signature is
to be verified. While DKIM does not make any assertions of content
validity, it offers a strong association between the From header field
and the DKIM signature! As such, it is of paramount importance that
spoofed header fields affect the disposition of the message.
It is unfortunate the base specification failed to stipulate message
rejection whenever singular header fields are found pre-pended to a
signed message where these are fields illegally redundant, and yet
likely displayed instead of the signed header fields actually associated
with the DKIM signature. Declaring the signature to be invalid when
policy is often lacking is unlikely to represent a reasonable status
able to properly control the disposition of the message.
As such, the added paragraph describing the attack falls short of
offering an appropriate remedy.
Here is alternative text:
,---
For example, a message with multiple From: header fields violates
Section 3.6 of [RFC5322]. With the intent of providing a better user
experience, many agents tolerate these violations and deliver the
message anyway. An MUA then might elect to render to the user the
value of the last, or "top", From: field. This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result. A pre-pended From header
field above one signed is an indication of likely malicious intent,
where the message SHOULD be refused.
A signer wishing to be resistant to this specific attack can include
in the signed header field list an additional instance of each field
that was present at signing. For example, a proper message with one
From: field could be signed using "h=From:From:..." Because of the
way header fields are canonicalized for input to the hash function,
this would prevent additional fields from being added, after signing,
as this would render the signature invalid.
'---
There is no reason to suggest a strong association of the From header
field with the DKIM signature is somehow diminished by the protocol not
authenticating the From header field separately. It is important to
_refuse_ messages when a From header field is likely to be confused with
an attempt to spoof the recipient. If this means setting back progress
of RFC advancement, retentions of the desired protections will make any
delay well worth it.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html