ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-06 14:08:18
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>