I will not pretend to know (nor really care) what it will take to get over this documentation dilemma but I will provide my comments here:
Murray S. Kucherawy wrote: > 8.14 Malformed Inputs > > > DKIM allows additional header fields to be added to a > signed message without breaking the signature. DKIM does not "allow" additional header fields. It just didn't check for conditions that were problematic. If this issue was obvious back during the TA work, we would not say this and the checks (exceptions) would be incorporated in Section 5.4 today. A better "friendlier" opening theme sentence is: There are known conditions which can alter the originality of a DKIM signed message without breaking the existing signature validity. > This tolerance can be abused, e.g. in a replay attack, by adding > additional instances of header fields that are displayed to the end > user or used as filtering input, such as From or Subject, to an > already signed message in a way that doesn't break the signature. This is close, but again, there is no "allowance" or a "tolerance" because, for the most part, DKIM was essentially "ignorant" of the conditions due to lack of vision during the TA. So I think the text following the opening theme could be: Since it is possible to maintain the integrity of the signature with these known non-compliant RFC5322 message alteration 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. > The resulting message violates section 3.6 of [MAIL]. What resulting message? The one DKIM ignorantly neglected to check? I think my text above covers the "blame" and IMO this sentence can be pulled. > The way such input will be handled and displayed by an MUA is > unpredictable, but in some cases it will display the newly added > header fields rather than those that are part of the originally > signed message alongside some "valid DKIM signature" annotation. This > might allow an attacker to replay a previously sent, signed message > with a different Subject, From or To field. I think handled and displayed can be seen as two different things or levels. Backend handling can be very predictable, Frontend displayed may not be since the MUA can be online or offline. Online can be predicted, offline less predictable but the odds are very high that what is shown offline will match what would be shown online for the simple reason systems that offer both modes take these offline vs online ergonomical issues into account to the best of its ability. We want the offline experience to match that of the online experience. We author a variety of MUA software from offline to online. Overall, there are certain messages headers that are expected to occur only once and thus including the overhead to parse or check for a 2nd or more header may not even be a considerations for some and even if it was, it could be viewed as redundant overhead. So its very predictable most parsers will mostly use the first header found and the only thing that is unpredictable is whether these special redundant overhead double header conditional checks are performed to a wide degree. I would change this to: 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. > Because of this, DKIM implementers are strongly advised to reject > or treat as suspicious any message that has multiple copies of header > fields that are disallowed by section 3.6 of [MAIL], particularly > those that are typically displayed to end users (From, To, Cc, > Subject). I am not sure about this. More below. > A signing module could return an error rather than generate a > signature; a verifying module might return a syntax error code > or arrange not to return a positive result even if the signature > technically validates. I am not sure about this because there are variations of solutions and I don't think the above covers them all. I would like to see something more generic that could cover in general the different ways DKIM processing may be integrated. Maybe text like: Despite the apparent scope of this requirement, there are implementation circumstances in which how DKIM processes these non-compliant RFC 5322 messages not be determined until it is known how 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 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. > Senders concerned that their messages might be particularly vulnerable to > this sort of attack and do not wish to rely on receiver filtering of > invalid messages can ensure that adding additional header fields will > break the DKIM signature by including two copies of the header fields > about which they are concerned in the signature (e.g. > "h= ... from:from:to:to:subject:subject ...). See Sections 3.5 > and 5.4 for further discussion of this mechanism. I would change this to: 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