[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields
dotis at mail-abuse.org
Tue Apr 26 10:48:41 PDT 2011
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
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.
More information about the ietf-dkim