Here's my proposal for a section in Security Considerations to talk about the
malformation issues that have been discussed on the list. This is an addition
to -02 directly and does not continue from any of the other proposals.
8.14 Malformed Inputs
The universe of email is replete with software that forgives messages which do
not conform strictly to the grammar that defines what valid email looks like.
This is a long-standing practice known informally as the robustness principle,
originally coined by Jon Postel: "Be conservative in what you do, be liberal in
what you accept from others."
A number of popular email packages, including MTAs, MLMs, MUAs and so forth,
thus forgive or ignore properties of messages that deviate from the standard
format. A frequent example involves violations of Section 3.6 of [MAIL] which
specifies minimum and maximum counts for particular header fields. Thus, a
message with more than one From or Subject header field is not a legal email
message, but most packages apply some trivial heuristic, e.g. use the first one
and ignore the others, to interfere minimally with delivery of mail that might
still be desirable to end users.
This can expose those packages to subtle abuse vectors. For example, two
different handlers of a message might identify the Subject field of a message
by choosing the first one it finds. This would always produce the same
result, regardless of whether the search is top-down or bottom-up, unless a
message had more than one Subject field. Although [MAIL] specifically
disallows this instance, it is tolerated by many mail handling agents, and so
the possibility of confusion among implementations exists.
This case becomes more interesting when one considers that a filtering agent
might make a filtering decision based on one header field instance but a user
agent might display the other. Knowing that this is the case, an attacker
seeking to fool a user might exploit this to get past filters and render false
data to a user.
DKIM exacerbates this concern by assigning a signature to part or all of a
message. It is possible that one could craft a message conforming to [MAIL],
then affix a DKIM signature to it, and then add header fields atop the message
that were not signed. Since many agents will overlook the fundamental
invalidity of such a message, a DKIM verifier might produce a "valid signature"
result while some other agent assumes an unsigned field is valid and applies it
(e.g., renders it to a user) alongside some indication attesting to the
message's validity. This is especially concerning where one of the fields in
question has to do with an identity, such as From or Sender.
Because of this, DKIM implementers are strongly advised to apply one or more of
the following design decisions:
1) During the handling of a message in conjunction with a DKIM result that
indicates a valid signature, consider as valid only those fields and the body
portion that was covered by the signature. Note that this is not to say
unsigned content is not valid, but merely that the signature is making no
statement about it.
2) Refuse outright to sign or verify any message that is not syntactically
valid.
3) For any header field listed in Section 3.6 of [MAIL] as having an upper
bound on the number of times it can appear, include the name of that field one
extra time in the "h=" portion of the signature to prevent addition of
fraudulent instances. Any attachment of such fields after signing would thus
invalidate the signature (see Section 3.5 and 5.4 for further discussion).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html