> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@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 identified author. 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. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html