On Sun, 03 Jul 2011 04:26:49 +0100, Barry Leiba
<barryleiba(_at_)computer(_dot_)org>
wrote:
Because of the extent of the changes, though, the chair (I) thinks it
needs to come back to the working group for another review. So the
working group is now asked to look over the diffs, noting that in a
few cases blocks of text were moved to other sections without being
changed. ONLY diffs are in scope for reconsideration at this point,
and we'll be looking for confirmation that the changes are acceptable,
as well as complaints about the changes. Complaints SHOULD come with
specific suggestions for alternatives. Pete apologizes for not having
been involved with this earlier, promises to closely follow the
mailing list thread on this, and will participate in any text
negotiation that's necessary in order to get this right.
We have a week. Murray will be posting the update (-14) very soon.
Please review and comment by 11 July.
Whilst any rewriting of the old sections 8.14 and 8.15 is to be welcomed,
the new section 8.15 does not quite fit the bill.
We may have decided that the attacks under discussion are not attacks
against DKIM as such, but it cannot be denied that it is the advent of
DKIM that has made them possible; and even if DKIM itself is not to
prevent them, it is still necessary to catch them somewhere. It is
therefore our responsibility, in our Security Considerations, to give
sufficient indication of the nature of these attacks for others to
understand precisely how they work, so that they can be countered in the
proper place(s). And the new 8.15 does not give sufficient detail for that
purpose, even though it clearly has those attacks in mind given that it is
headed "Attacks Involving Addition of Header Fields" (though I would
s/Addition of/Extra/ since in some attacks the extra headers were present
from the start).
Here, therefore, is my proposed revision of 8.15 (which still includes
most of Pete's new text).
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 by having multiple instances
of From: header fields (or of other fields which are supposed to
occur only once). Equally, it might contain data that constitutes an
attack, such as falsely indicating the name of the author (perhaps
via such an extra From: field). 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 the first of any multiple From: header fields).
Recall that, when multiple instances of a given header field are
present, they are signed starting with the last one and working
upwards (section 5.4.2). A variety of attacks taking advantage of
this feature can be envisaged. In some, the attacker is himself the
signer, signing the second of some duplicated field on behalf of his
own domain, whilst hoping that some lenient MUA will display only the
first. In others, a genuine signature from the domain under attack is
obtained by legitimate means, but extra header fields are then added,
either by interception or by replay.
Indeed, in the latter scenario DKIM can aid in detecting such
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 unverifiable (see Section 3.5 for details). This in
essence is an explicit indication that the signer repudiates
responsibility for any such malformed message. However, this
technique offers no protection in the first scenario.
DKIM signs and validates the data it is told to and works correctly.
So in these cases, 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 (section 2.7)
or some other subsequent agent to act on such signed but malformed
messages as needed, such as by degrading the trust of the message
(or, indeed, of the signer) or by warning the recipient (or even by
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 thus need to revisit that posture when
incorporating DKIM, especially when considering matters of potential
attacks such as those described.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html