Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On 26/Oct/10 19:08, Murray S. Kucherawy wrote: On Behalf Of Alessandro Vesely On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? In a bunch of ways. In particular, though, it is deliberately not RFC2119 language, partly because that's not generally done in Security Considerations since that section is discussion (informative) rather than protocol (normative). But it affects the result! That way a verifier is encouraged to determine the validity of a signature based on heuristic criteria. This kind of checking belongs to scam filters a la SpamAssassin. Now, SA doesn't do it. Possibly, that's because it's statistically irrelevant. AFAIK, SA does not even analyze Authentication-Results, but re-checks signatures anew. Why? Suppose one day the double-From attack becomes trendy and SA developers will want to write code that checks for the valid-signature + added-From pattern. They would never be able to use A-R, because those results might be flawed by such non-normative arrangements: This is where that layer violation hurts. According to that text, it is strongly advised to have a scam filter /integrated/ within a DKIM verifier. Doesn't this slash the value of stand alone verifiers and A-R fields? JM2C ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
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
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
Alessandro Vesely wrote: On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? I think it creates an IETF procedural bug and will promote another round of reviews or something like that. :) -- 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
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On Oct 26, 2010, at 1:49 AM, Hector Santos wrote: 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. Yes, it does. Section 5.4 of 4871 goes into quite a lot of detail about that, and explains explicitly that you should list a header n+1 times if there are n copies of it already if you don't want to allow more headers to be added, or not if you do. It's also quite clear about the need to sign user-visible fields. All we're doing in this thread is pulling those two points together, and adding a dash of observed MUA behaviour w.r.t. messages with multiple Subject headers. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
Steve Atkins wrote: On Oct 26, 2010, at 1:49 AM, Hector Santos wrote: Murray S. Kucherawy wrote: 8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. This tolerance can be abused.. DKIM does not allow additional header fields. Yes, it does. Section 5.4 of 4871 goes into quite a lot of detail about that, and explains explicitly that you should list a header n+1 times if there are n copies of it already if you don't want to allow more headers to be added, or not if you do. I see the intent but it can reworded. I think my nit which I did not express, was how the immediate tolerance sentence that followed the opening text negatively alters its implied meaning. There is no tolerance. Its a DKIM feature and also a nature act of email operations for additional unsigned fields to exist, i.e. transport trace fields added to the already signed message. Maybe a better text might be: Per section 5.4, DKIM signed message allows the existence of unsigned header fields or additional unsigned headers added to the message during the transport process without breaking the original signature. This natural email functionality can be abused with the introduction of non-compliant RFC 5322 messages with two or more headers that can only exist once per RFC 5322. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Tuesday, October 26, 2010 2:59 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues) On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? In a bunch of ways. In particular, though, it is deliberately not RFC2119 language, partly because that's not generally done in Security Considerations since that section is discussion (informative) rather than protocol (normative). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On Oct 25, 2010, at 9:58 PM, Murray S. Kucherawy wrote: 8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. 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. The resulting message violates section 3.6 of [MAIL]. 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. 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). 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. 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. Looks fine to me (other than some light wordsmithing of the final paragraph - look like there's a who or who are missing). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Tuesday, October 26, 2010 3:38 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues) +0.999 My only niggle is where you say dissallowed by section 3.6 of [MAIL], you might want to add a reference to the RFC 2045 which defines the MIME headers. OK. You might also want to mention RFC 4021 which is a laundry list of every known message header. What about referring to the IANA header field registry? 4021 was just the primer for that. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
+0.999 My only niggle is where you say dissallowed by section 3.6 of [MAIL], you might want to add a reference to the RFC 2045 which defines the MIME headers. OK. You might also want to mention RFC 4021 which is a laundry list of every known message header. What about referring to the IANA header field registry? 4021 was just the primer for that. Makes sense. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. 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. The resulting message violates section 3.6 of [MAIL]. 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. 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). 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
