[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

[Douglas Otis]

On 4/25/11 9:18 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Douglas Otis
>> Sent: Monday, April 25, 2011 6:33 PM
>> To: ietf-dkim at mipassoc.org; Barry Leiba; Pete Resnick
>> Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving
>> Additional Header Fields
>>
>> Double listing in the "h=" tag can not fully mitigate risks related to
>> appended header fields when messages are signed by a different domain
>> than the domain found in the appended From header field.
> DKIM doesn't create any binding between the RFC5322.From domain and the "d=" value as you're doing.  What you're talking about here falls into the realm of ADSP or other policy-like assertions, not DKIM itself which is the topic of this draft.
Agreed.  The "d=" domain within the DKIM-Signature header field and the 
 From header field may be bound by acceptance policies perhaps due to 
ADSP publications or private arrangements.  It is the From header, not 
the DKIM-Signature header field, most likely seen and sorted by 
recipients, although acceptance may have been based upon DKIM-Signature 
domains.

Security Consideration section 9.14 will not protect phished domains 
where recipients may depend upon policy constraints that bind From and 
the DKIM-Signature field domains.  Unfortunately, despite the protective 
policies and double listings recommended in section 9.14, phished 
domains will still find their From header fields accepted and spoofed 
when signed by otherwise uninvolved "too big to block" domains.

The lack of protection is due to the _base_ DKIM specification omitting 
checks necessary to prevent inadvertent endorsement of replayed messages 
carrying bogus pre-pended From header fields added to a message 
previously originated and signed by an otherwise uninvolved domain that 
may not have a problem with phishing.

Do you see any problem with the suggested remedy?  Section 9.14 still 
supports prior versions of DKIM verifiers although the double listing 
strategy would offer limited protection that appears to assume 
DKIM-Signature domains are somehow visible.

-Doug