On 10/24/10 9:05 PM, Murray S. Kucherawy wrote:
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.
Bad advice. There is no other email component that can be relied upon to
restore flawed DKIM verification results, nor should DKIM relegate
determination of DKIM result validity to subsequent consumers. This
would be expecting all subsequent stages of email, represented by
thousands of different applications, to repeat tests that now MUST be
made to mitigate exploits. Without a MUST requirement in the
verification process with respect to multiple From header fields, no
DKIM results can be trusted for subsequent display or sorting
processing. Nor should these processes be expected to conform with the
DKIM bottom-up selection of headers that MUST be singular to be
compliant with RFC5322.
2) Refuse outright to sign or verify any message that is not
syntactically valid.
Good advice. However, without a MUST normative language, DKIM results
will be prone to attack. It is not reasonable to suggest consumers of
DKIM results check "something" "somewhere". This is NOT about enforcing
compliance, this is about ensuring safe and actionable DKIM results.
This can only be specified by the DKIM protocol. While lack of RFC5322
compliance might go unnoticed, a DKIM verifier MUST NEVER indicate a
message with multiple From headers receive a PASS.Policy components
could then indicate specific message handling.
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).
Incomplete advice. This only provides partial protection, since it does
not prevent spoofing of a From header where an attacker controls or
utilizes a domain that does not include repeated From header entries
within the h= parameter.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html