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