[ietf-dkim] Final update to 4871bis for working group review
Murray S. Kucherawy
msk at cloudmark.com
Wed Jul 6 11:34:43 PDT 2011
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Barry Leiba
> Sent: Wednesday, July 06, 2011 9:32 AM
> To: Charles Lindsey
> Cc: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> As Pete has pointed out -- and has he's adamant about -- the signer
> can't attack... that is, DKIM can't do anything about "attacks" by the
> signer. And that's as Charles's text itself points out. So I'd be
> happy merging just the last sentence with the next paragraph, and
> eliminating the rest:
Interesting side note: Given the reference to Postel's Law being not-such-a-good-idea-after-all, it would be nice if this could make a forward reference to the malformed mail BCP under development. That can't happen, so instead, we can perhaps just refer to this text from that document.
Anyway, with a few nitty edits from me as well, here's the current 8.15 for -15 for everyone's consideration. I concur with Barry with respect to the DISCUSS complaint about who's attacking what. Also, the second paragraph already alludes to the fact that multiple From: fields is a problem regardless of whether or not one of them is signed. I think it covers the bases and flows nicely.
Also, to be more precise about the deadline for this review, the cutoff for posting this is July 11th at 5pm PDT, so I would like to post it that morning if possible, giving the ADs time to look at it and bounce it to us for changes if needed.
8.15. Attacks Involving Extra Header Fields
DKIM is able to sign and validate many types of messages that might
cause problems elsewhere in the message system. The message might
violate some part of [RFC5322], such as having multiple From: fields
(or of other fields that are supposed to occur only once), or other
malformed fields. Equally, it might contain data that constitutes an
attack on the recipient, such as falsely indicating the name of the
author. These can represent serious attacks, but they have nothing
to do with DKIM; they are attacks on the recipient, or on the wrongly
Many email components, including MTAs, MSAs, MUAs and filtering
modules, implement message format checks only loosely. This is done
out of years of industry pressure to be liberal in what is accepted
into the mail stream for the sake of reducing support costs;
improperly formed messages are often silently fixed in transit,
delivered unrepaired, or displayed inappropriately (e.g., by showing
only one of multiple From: fields).
A genuine signature from a domain under attack can be obtained by
legitimate means, but extra header fields can then be added, either
by interception or by replay. In this scenario, DKIM can aid in
detecting addition of specific fields in transit. This is done by
having the signer list the field name(s) in the "h=" tag an extra
time (e.g., "h=from:from:..." for a message with one From field), so
that addition of an instance of that field downstream will render the
signature unable to be verified. (See Section 3.5 for details.)
This in essence is an explicit indication that the signer repudiates
responsibility for such a malformed message.
DKIM signs and validates the data it is told to and works correctly.
So in this case, DKIM has done its job of delivering a validated
domain (the "d=" value) and, given the semantics of a DKIM signature,
essentially the signer has taken some responsibility for a
problematic message. It is up to the identity assessor or some other
subsequent agent to act on such messages as needed, such as degrading
the trust of the message (or, indeed, of the signer), or by warning
the recipient, or even refusing delivery.
An agent consuming DKIM results needs to be aware that the validity
of any header field, signed or otherwise, is not guaranteed by DKIM.
All components of the mail system that perform loose enforcement of
other mail standards will need to revisit that posture when
incorporating DKIM, especially when considering matters of potential
attacks such as those described.
More information about the ietf-dkim