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
