For readability, I will propose my 8.14 text change suggestions as a whole:
8.14 Non-Compliant RFC5322 Messages There are known conditions which can alter the originality of a DKIM signed message without breaking the existing signature validity. Since it is possible to maintain the integrity of the signature with known non-compliant RFC5322 message altered conditions, there is an increase possibility of abuse and exploitation of MUA displaying information which were not validated by the signature. Examples may be non-compliant RFC 5322 messages containing a 2nd 5322.From or 2nd Subject headers which were not hash bound to the DKIM signature, yet due to the nature of MUAs, the wrong header could be displayed to end-users. It is unknown how these non-compliant RFC5322 messages will be handled by backend MTA receivers and how MUAs will display them. It is conceivable, some MTAs will reject these messages while other MTAs may accept it but only after it has sanitize the message for user display. Yet other MTAs may be unaware of the multiple headers in these non-compliant RFC5322 messages. Under unchecked conditions, this can allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Despite the apparent scope of this requirement, there are implementation circumstances in which how DKIM processes these non-compliant RFC 5322 messages can not be determined until it is known how these messages are first passed or reach integrated DKIM processors. With an increase alertness of the possibility for these non-conforming RFC5322 yet DKIM compliant messages, receiver MTA may begin to perform this filtering at an increase level. This recommended form of processing will minimize any implementation requirement for DKIM to perform this non-compliant mail check. In addition, enhanced MUA operations can address the situation as well with attentive awareness of non-compliant message displays. To address current or legacy email implementations that may not aware of these non-compliant RFC 5322 double header messages, DKIM Signers concerned their signed outbound messages might be particularly vulnerable to this form of attack can ensure that adding unexpected additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature h= tag e.g. "h= ... from:from:to:to: subject:subject...". See Sections 3.5 and 5.4 for further discussion of this mechanism. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html