Re: [ietf-dkim] Final update to 4871bis for working group review
On Wed, 6 Jul 2011, Barry Leiba wrote: As Pete has pointed out -- and has he's adamant about -- the signer can't attack... that is, DKIM can't do anything about attacks by the signer. Under the double-From: exploit Otis is so concerned about, one signer can (given favorable winds) trick an end-user into thinking his message was signed properly *by someone else*. So indeed, a signer can attack. Although I still don't agree with Otis' demands for extra language in the RFC. Really, his case would make sense if there was some squad of thugs ready to force every mail-admin to implement DKIM, but only to the strict letter of the final RFC. Then putting that in might make a difference -- but so would throwing in a whole bunch of other unrelated anti-abuse best practices. In real life, however, if you don't have the power to demand that a recipient mail admin block incoming double-From: messages, then you don't have the power to demand that they deploy DKIM at all. Michael Deutschmann mich...@talamasca.ocis.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Wed, 06 Jul 2011 21:51:49 +0100, Hector Santos hsan...@isdg.net wrote: My only comment is that we are making way too much out of this. DKIM requires a From: hashing a minimum requirement and since RFC5322 only one there are two basic fundamentals rules, together called the One From DKIM Rule: One From DKIM Rule: Verify - DKIM must only see one From when verifying. If multiple From: headers are found, the message is automatically invalid from a valid DKIM signature standpoint. Signing - DKIM must only see one From when signing. If multiple From: headers are found, the message is automatically invalid for a DKIM signature standpoint. In other words, it MUST NOT continue and sign the message. I agree with the above entirely, and have proposed such wordings many times. But unfortunately the consensus of the WG has been to not include such wordings. Dealing with Exploits: For the most part, we are dealing with injection of addition From: header(s) in an already signed message. DKIM implementations following the One From DKIM Rule, will mitigate this problem. No, I think my first scenario, where the attacker signs on behalf of his throwaway domain, will turn out to be the more common attack, if we do not fix this problem. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Wed, 06 Jul 2011 17:31:47 +0100, Barry Leiba barryle...@computer.org wrote: I actually like Charles's edits except for one paragraph, and, as a participant, would be happy to change 8.15 accordingly. The one problem paragraph is this one: On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey c...@clerew.man.ac.uk wrote: ... Recall that, when multiple instances of a given header field are present, they are signed starting with the last one and working upwards (section 5.4.2). A variety of attacks taking advantage of this feature can be envisaged. In some, the attacker is himself the signer, signing the second of some duplicated field on behalf of his own domain, whilst hoping that some lenient MUA will display only the first. In others, a genuine signature from the domain under attack is obtained by legitimate means, but extra header fields are then added, either by interception or by replay. As Pete has pointed out -- and has he's adamant about -- the signer can't attack... that is, DKIM can't do anything about attacks by the signer. And that's as Charles's text itself points out. So I'd be happy merging just the last sentence with the next paragraph, and eliminating the rest: The signer most certainly CAN attack, but what he is attacking is not DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in fact, his weapon of attack. I carefully included two scenarios in my paragraph, which you quote above, because they are subtly different attacks. The 1st is the more pernicious IMHO and the hardest to counter, since the 'h=from:from:' defence does not work. I therefore regard it as ESSENTIAL that our Security Considerations give warning of that scenario. Moreover, it is also necessary to draw attention to the 'working upwards' signing order, which is at the heart of both scenarios, since that might not otherwise be clear to the reader. I would be happy to reword my paragraph to make it clear that these attacks are not against DKIM (although that point is also made strongly in a later paragraph). How about the following? Recall that, when multiple instances of a given header field are present, they are signed starting with the last one and working upwards (section 5.4.2). This DKIM feature can be deployed to mount a variety of attacks against the email system. In some, the attacker is also the signer, signing the second of some duplicated field on behalf of his own domain, whilst hoping that some lenient MUA will display only the first. In others, a genuine signature from the domain under attack is obtained by legitimate means, but extra header fields are then added, either by interception or by replay. and then my following paragraph as they stand. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 06/Jul/11 20:34, Murray S. Kucherawy wrote: Anyway, with a few nitty edits from me as well, here's the current 8.15 for -15 for everyone's consideration. A few comments: 8.15. Attacks Involving Extra Header Fields [...] Many email components, including MTAs, MSAs, MUAs and filtering modules, implement message format checks only loosely. This is done out of years of industry pressure to be liberal in what is accepted into the mail stream for the sake of reducing support costs; improperly formed messages are often silently fixed in transit, delivered unrepaired, or displayed inappropriately (e.g., by showing only one of multiple From: fields). I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) A genuine signature from a domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the signer list the field name(s) in the h= tag an extra time (e.g., h=from:from:... for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This in essence is an explicit indication that the signer repudiates responsibility for such a malformed message. +1 for exemplifying h=from:from:..., even if it's not a cure-all. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the d= value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a problematic message. It is up to the identity assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the signer), or by warning the recipient, or even refusing delivery. I'd omit any allegation on what an assessor's needed actions might be. (Actually, we'd need yet another policy or authentication method in order to allow the outcome of an identity assessor to be formally expressed. Without it, the quick-n-dirty approach of degrading the trust of a message by tampering with its DKIM verification's results may seem the easiest remedy --much like what Doug et al. proposed.) An agent consuming DKIM results needs to be aware that the validity of any header field, signed or otherwise, is not guaranteed by DKIM. Please, s/validity/reliability/: someone might believe a field is valid if it retains the value that was given to it originally. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/6/2011 10:59 PM, Michael Deutschmann wrote: Under the double-From: exploit Otis is so concerned about, one signer can (given favorable winds) trick an end-user into thinking his message was signed properly *by someone else*. So indeed, a signer can attack. A signer can attack a recipient. A signer cannot attack DKIM's mechanisms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, July 07, 2011 3:09 AM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review The signer most certainly CAN attack, but what he is attacking is not DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in fact, his weapon of attack. But all of those attacks exist today even without DKIM, so I don't see how DKIM becomes the weapon. Even more simple attacks involve use of the display name, something none of this work has even tried to handle (nor should it). It seems to me we're anticipating improper application of a DKIM pass here by MUAs or other agents and thus making the leap to calling DKIM a weapon. In that light, MIME is also a weapon. And so is RFC5322. And so is HTML. The current 8.15 text explains what a DKIM pass does and doesn't tell us rather clearly. I'm wary of enumerating specific attacks and would prefer to use more general terms, as we have done here; such an effort might be taken as exhaustive. I carefully included two scenarios in my paragraph, which you quote above, because they are subtly different attacks. The 1st is the more pernicious IMHO and the hardest to counter, since the 'h=from:from:' defence does not work. I therefore regard it as ESSENTIAL that our Security Considerations give warning of that scenario. Moreover, it is also necessary to draw attention to the 'working upwards' signing order, which is at the heart of both scenarios, since that might not otherwise be clear to the reader. In your scenario, the modules that operate on the signature result are able to observe that the signer took responsibility for a malformed message and can take appropriate action, degrading the signer's reputation, interfering with inbox delivery, or both. I would be happy to reword my paragraph to make it clear that these attacks are not against DKIM (although that point is also made strongly in a later paragraph). How about the following? [...] I believe the current text is adequate in that it lays out the semantics of a pass more clearly. I don't think calling out the two-froms-one-signed case explicitly will improve what's there. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Thursday, July 07, 2011 4:56 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) You're either liberal in your application of the RFCs, or you're not. I don't see how adding that word improves things here. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the d= value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a problematic message. It is up to the identity assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the signer), or by warning the recipient, or even refusing delivery. I'd omit any allegation on what an assessor's needed actions might be. Such as makes it clear these are only possible actions (and the obvious ones). It's not an exhaustive list. (Actually, we'd need yet another policy or authentication method in order to allow the outcome of an identity assessor to be formally expressed. Without it, the quick-n-dirty approach of degrading the trust of a message by tampering with its DKIM verification's results may seem the easiest remedy --much like what Doug et al. proposed.) If the role of the identity assessor is reputation, and we decide later that we want reputation to be relayed to downstream agents, we can extend RFC5451 by such a registration then. It doesn't make sense to do it here though. An agent consuming DKIM results needs to be aware that the validity of any header field, signed or otherwise, is not guaranteed by DKIM. Please, s/validity/reliability/: someone might believe a field is valid if it retains the value that was given to it originally. Isn't that conclusion precisely what this sentence is countering? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote: ... In real life, however, if you don't have the power to demand that a recipient mail admin block incoming double-From: messages, then you don't have the power to demand that they deploy DKIM at all. ... I think you are confusing protocol with implementation. There's nothing the prevents receivers from ensuring messages that have been modified after signing with an additional From fail verification. I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote: I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) You're either liberal in your application of the RFCs, or you're not. I don't see how adding that word improves things here. well, it keeps the thread going... DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the d= value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a problematic message. It is up to the identity assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the signer), or by warning the recipient, or even refusing delivery. I'd omit any allegation on what an assessor's needed actions might be. Such as makes it clear these are only possible actions (and the obvious ones). It's not an exhaustive list. Huh? You mean that listing examples is not the same thing as specifying directives or even similar to implying obligation? You mean, an example is merely and example of what is possible? As in... example. gosh. (Actually, we'd need yet another policy or authentication method in order to allow the outcome of an identity assessor to be formally expressed. Without it, the quick-n-dirty approach of degrading the trust of a message by tampering with its DKIM verification's results may seem the easiest remedy --much like what Doug et al. proposed.) If the role of the identity assessor is reputation, and we decide later that we want reputation to be relayed to downstream agents, we can extend RFC5451 by such a registration then. It doesn't make sense to do it here though. It might make a great deal of sense to do it here, if we were specifying a tightly integrated, inflexible, and self-contained end-to-end reputation service. But since we aren't, modularity of specification scope is the norm for a reason. An agent consuming DKIM results needs to be aware that the validity of any header field, signed or otherwise, is not guaranteed by DKIM. Please, s/validity/reliability/: someone might believe a field is valid if it retains the value that was given to it originally. Isn't that conclusion precisely what this sentence is countering? The word reliability has no meaning in this context. On the other had, misunderstandings about implied or actual data validity is /exactly/ the issue this text is /intended/ to cover. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/6/2011 10:59 PM, Michael Deutschmann wrote: Under the double-From: exploit Otis is so concerned about, one signer can (given favorable winds) trick an end-user into thinking his message was signed properly *by someone else*. So indeed, a signer can attack. A signer can attack a recipient. A signer cannot attack DKIM's mechanisms. I would also be interested in seeing an example of a case where adding an extra From: line changles the d= in a DKIM signature. 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
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/7/2011 7:18 AM, John R. Levine wrote: I would also be interested in seeing an example of a case where adding an extra From: line changles the d= in a DKIM signature. no you wouldn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 6:32 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. This intentionally causes the verifier to assume what the signer really meant when it signed a message using a single From: field. That may look safe but it isn't what DKIM actually says. We might do this for libopendkim somewhere down the line, but it would default off. In any case, interesting idea. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 6:32 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. This intentionally causes the verifier to assume what the signer really meant when it signed a message using a single From: field. That may look safe but it isn't what DKIM actually says. We might do this for libopendkim somewhere down the line, but it would default off. In any case, interesting idea. It only assumes that the signer signed all the From: fields present in the message (note: I said one more than in h=, not two). I think it's fair to say that if someone is sending messages with multiple From: fields (or Date:/Subject:) and trying to sign something less than all of them they are fairly deep into unsupported territory and shouldn't find any result surprising. I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current describe it and let implementors deal with it plan. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
I don't think so, but I'll definitely test it. If it does, then we won't do it that way. Scott K On Thursday, July 07, 2011 12:51:06 PM McDowell, Brett wrote: Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 12:44 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 6:32 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. This intentionally causes the verifier to assume what the signer really meant when it signed a message using a single From: field. That may look safe but it isn't what DKIM actually says. We might do this for libopendkim somewhere down the line, but it would default off. In any case, interesting idea. It only assumes that the signer signed all the From: fields present in the message (note: I said one more than in h=, not two). I think it's fair to say that if someone is sending messages with multiple From: fields (or Date:/Subject:) and trying to sign something less than all of them they are fairly deep into unsupported territory and shouldn't find any result surprising. I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current describe it and let implementors deal with it plan. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list- rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 9:44 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current describe it and let implementors deal with it plan. It's definitely not proscribed by DKIM. All I meant was that you're preventing a signer from deliberately accepting responsibility for a message thus modified (by doing only one from in h=), knowing the risks of doing so. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 12:44 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 6:32 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. This intentionally causes the verifier to assume what the signer really meant when it signed a message using a single From: field. That may look safe but it isn't what DKIM actually says. We might do this for libopendkim somewhere down the line, but it would default off. In any case, interesting idea. It only assumes that the signer signed all the From: fields present in the message (note: I said one more than in h=, not two). I think it's fair to say that if someone is sending messages with multiple From: fields (or Date:/Subject:) and trying to sign something less than all of them they are fairly deep into unsupported territory and shouldn't find any result surprising. I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current describe it and let implementors deal with it plan. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list- rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 12:47:52 PM Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 9:44 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current describe it and let implementors deal with it plan. It's definitely not proscribed by DKIM. All I meant was that you're preventing a signer from deliberately accepting responsibility for a message thus modified (by doing only one from in h=), knowing the risks of doing so. Yes. I can live with that. Thanks, Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
I am perfectly happy with Murray's original (and now, revised) text. (Nits still being discussed are entirely up to the WG.) I am not happy with Charles's text. Particularly: On 7/7/11 5:08 AM, Charles Lindsey wrote: Recall that, when multiple instances of a given header field are present, they are signed starting with the last one and working upwards (section 5.4.2). This DKIM feature can be deployed to mount a variety of attacks against the email system. In some, the attacker is also the signer, signing the second of some duplicated field on behalf of his own domain, whilst hoping that some lenient MUA will display only the first. In others, a genuine signature from the domain under attack is obtained by legitimate means, but extra header fields are then added, either by interception or by replay. It seems like this text is tailor-made to obfuscate who is doing the attacking and who is being attacked. It's this distinction that I think is the most important to make, and the above text simply does not clarify; it muddies the waters. DKIM can only be deployed to mount a variety of attacks if the recipient has already made the fatal mistake of assuming that the existence of a cryptographically valid signature *means* that the message is reliable and from a known good sender. You could have a longer and more detailed discussion in the document about how broken it is for a recipient to do such a thing, and put *that* into the security consideration, but I don't think it's necessary. The above can only obfuscate that very important point, making it out as if it's something in the DKIM signing/verifying process that caused the problem. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thu, 07 Jul 2011 15:28:09 +0100, Barry Leiba barryle...@computer.org wrote: The signer most certainly CAN attack, but what he is attacking is not DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in fact, his weapon of attack. Right, but the point is that, with DKIM (as Murray says, this attack can be mounted with or without), the signing domain is relying on its own reputation, not that of the fake From I think Murray is wrong. There is no benefit to the Bad Guy in using two From: fields if he is not going to sign one of them. By signing, he hopes to gain sufficient extra credibility to get through. ... That mitigates things in two ways: 1. There's really no difference between using d=badguy.com to sign From: x...@badguy.com and then adding From: x...@ebay.com later, and using d=badguy.com to sign From: x...@ebay.com in the first place. No advice in this regard addresses the second case anyway. Oh yes there is! Because identity assessors will undoubtedly give more credence to messages where the signature domain is the same as the author (i.e.From:) domain, even if they do not go to the extent of doing full ADSP, and that is just what the BadGuy hopes will happen. And if implementors are not warned of this attack, they will tend to take a report of signed by the domain that DKIM regards as the appropriate From: at its face value and act accordingly. 2. Signers that do this will quickly get bad reputations, and will never have had strongly good ones in the first place. It's never eBay's reputation that's relevant here anyway. Signers who are BadGuys don't give a damn about the reputation of their domains. Having displatched a million or so phishes with d=badguy.com, they will abandon that domain and use d=son-of-badguy.com for the next batch. All that can be said of the reputation of badguy.com is that it is a new domain, never seen before (but new domains are appearing all the time, and must be assumed more-or-less innocent until proven otherwise). Given all that, having us describe the problem is sufficient, and that's exactly what the WG consensus has us do. Yes, but you haven't described the problem. In draft-12, the old 8.14 described this attack tolerably well (and 8.15 described my 2nd one). On that basis I was persuaded to let that draft go (just). But what we have now is worse, not better, and I regret that if that remains the case, then it can only lead to another appeal to the AD. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/7/2011 12:41 PM, John R. Levine wrote: Oh yes there is! Because identity assessors will undoubtedly give more credence to messages where the signature domain is the same as the author (i.e.From:) domain, ... My spam filters don't do that. as well they shouldn't. Somehow, validating a From: field of bad-ac...@bad-host.example.com does provide any obvious basis for giving more 'credence' to the trustworthiness of the author or the message content. but this does raise the question of how many times this point needs to be made? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, July 07, 2011 12:31 PM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I think Murray is wrong. There is no benefit to the Bad Guy in using two From: fields if he is not going to sign one of them. By signing, he hopes to gain sufficient extra credibility to get through. My favourite counterexample, which I've used many times already, is Mailman. It doesn't even check DKIM signatures, but you can still fake your way through its authorization process such that a different From: is shown to the user for some MUAs. This still supports the notion that we fear people will misapply DKIM results as the basis for the attack. Your proposed changes here won't remedy that. Oh yes there is! Because identity assessors will undoubtedly give more credence to messages where the signature domain is the same as the author (i.e.From:) domain, even if they do not go to the extent of doing full ADSP, and that is just what the BadGuy hopes will happen. Whose? Mine don't, and the text doesn't support that notion either. And if implementors are not warned of this attack, they will tend to take a report of signed by the domain that DKIM regards as the appropriate From: at its face value and act accordingly. Where in the bis document is that notion supported or even suggested? I think the opposite is done in several places. Signers who are BadGuys don't give a damn about the reputation of their domains. Having displatched a million or so phishes with d=badguy.com, they will abandon that domain and use d=son-of-badguy.com for the next batch. All that can be said of the reputation of badguy.com is that it is a new domain, never seen before (but new domains are appearing all the time, and must be assumed more-or-less innocent until proven otherwise). Certainly true, and certainly fodder for a BCP for using DKIM or even reputation, but not for the DKIM protocol specification (especially since we declared reputation out-of-scope ages ago). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 7/7/11 10:09 AM, Pete Resnick wrote: DKIM can only be deployed to mount a variety of attacks if the recipient has already made the fatal mistake of assuming that the existence of a cryptographically valid signature *means* that the message is reliable and from a known good sender. Strongly disagree! Security must consider what is meant by verification. The fact that a signature appears valid although _significant_ visible aspects of the message's author, subject, date, etc can be altered represents a clear threat and a present danger in the verification process that also threatens policy layers such as ADSP! Ensuring verification is not deceptive does not represent a layer violation. Expecting consumers of DKIM results to guess whether critical verification aspects were checked is a layer and a trust violation! A layer violation since DKIM MUST understand critical aspects of the verification process! A violation in trust since offering a verification pass for a message with multiple From header fields is clearly negligent. Had the pre-pended exploit not been missed in the original threat review, the verification process would NOT have over looked this serious failing. The expressed goal was to ensure subsequent processes not be DKIM aware for safe and incremental DKIM deployment. While there are many ways a malefactor might attempt to deceive recipients, due to the verification flaw any false expectation that DKIM used by a phished domain offers protection places recipients in even greater peril. This may even invite the phishing that DKIM was intended to help mitigate. With this verification flaw, reputation CAN NOT offer protection when misapplied to grant acceptance of deceptive messages. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? The RFC also says you shouldn't sign messages that aren't RFC 2822. So pick your poison. I have to say it's a little surreal to have these arguments about what changes to make to avoid the horrors of a duplicate From: attack that is and likely will always be entirely hypothetical, when we can't even get our act together to deprecate the l= option, including l=0. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Jul 7, 2011, at 3:21 PM, John Levine wrote: Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? The RFC also says you shouldn't sign messages that aren't RFC 2822. So pick your poison. I have to say it's a little surreal to have these arguments about what changes to make to avoid the horrors of a duplicate From: attack that is and likely will always be entirely hypothetical, when we can't even get our act together to deprecate the l= option, including l=0. It is. This group finds it much easier to add cruft (or argue that cruft should be added) than to remove cruft. But we're past the point where we can improve things on this round of the spec. Time to move on. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
Pete Resnick wrote: I am perfectly happy with Murray's original (and now, revised) text. (Nits still being discussed are entirely up to the WG.) I am not happy with Charles's text. Particularly: On 7/7/11 5:08 AM, Charles Lindsey wrote: Recall that, when multiple instances of a given header field are present, they are signed starting with the last one and working upwards (section 5.4.2). This DKIM feature can be deployed to mount a variety of attacks against the email system. In some, the attacker is also the signer, signing the second of some duplicated field on behalf of his own domain, whilst hoping that some lenient MUA will display only the first. In others, a genuine signature from the domain under attack is obtained by legitimate means, but extra header fields are then added, either by interception or by replay. It seems like this text is tailor-made to obfuscate who is doing the attacking and who is being attacked. It's this distinction that I think is the most important to make, and the above text simply does not clarify; it muddies the waters. DKIM can only be deployed to mount a variety of attacks if the recipient has already made the fatal mistake of assuming that the existence of a cryptographically valid signature *means* that the message is reliable and from a known good sender. You could have a longer and more detailed discussion in the document about how broken it is for a recipient to do such a thing, and put *that* into the security consideration, but I don't think it's necessary. The above can only obfuscate that very important point, making it out as if it's something in the DKIM signing/verifying process that caused the problem. pr I don't quite follow. There seems to be this effort to remove a bad (erroneous or not) connotation about DKIM (for some rubber stamping reason) when the facts are there is a strong possibility of a problem only because DKIM raises the bar or something in regards to email. I strongly believe the mail industry never had a problem (at least I don't ever remember an exploit) because most, if not all, was designed to read mail for one FROM. There is no need to continue reading, reading from the bottom either, normal sequential reading for the From: field found. In other words, I doubt any software has a COLLECTION concept for From fields. Why when there there was no need for it. So the first one read was the one shown or the one used for gateway transformations, which is a strong point here - not every backend mail system stores mail in pure RFC x822/5322 format. I would like to see one software, any software that holds a structure for multiple froms? I doubt it exist. Hence, that is why we never saw the problem. But now with DKIM, it changes the issues somehow. DKIM allows for a perfect cryptographic valid signature for any bits it ignorantly signs and that includes all headers. In fact, I know of one API that without any IMPLEMENTATION controls - it will, by default, sign all headers, including if there exist multiple From: headers. You MUST recode the API if you want to invalidate the signing of an illegal RFC5322 message with multiple froms. Ironically, the same API did make a change to check for multiple froms during the verification process, but it did nothing on the signing side. I guess that might be ok when the design presumption is that the implementation of the API will make sure the input is valid during signing. In any case, I think the protocol should include both a functional and technical requirement for a ONE FROM criteria during the signing and verification process. I agree with Doug that at some point DKIM will have some meaning for validity and I think it is best that DKIM doesn't continue signing or verify an illegal RFC5322 message even if the mechanism allows for a valid abstract signature. Finally, in my implementation opinion, the only thing that makes me wonder is how far do we go to address the legacy verifiers who are not going to check for multi-from message. Do we add the h=From*n+1 kludge? Well, we decided that as long as we allow the h= setting to be flexible for the operator, then they can add it (we add it by default) as a short term solution. In the long term, I don't think it has to be used, but then again, I am strongly basing that that most DKIM implementations will eventually use a ONE FROM RULE criteria for both signing and verifying. -- 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] Final update to 4871bis for working group review
On 7/7/11 3:21 PM, John Levine wrote: Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? The RFC also says you shouldn't sign messages that aren't RFC 2822. So pick your poison. I have to say it's a little surreal to have these arguments about what changes to make to avoid the horrors of a duplicate From: attack that is and likely will always be entirely hypothetical, when we can't even get our act together to deprecate the l= option, including l=0. John, When a domain is found using the l=0 option, this provides a basis to assign the domain with no positive reputation. In other words, this domain's signature can not be a basis for acceptance hence reputation is able to cure this ill. The specification of SHOULD ensure messages are RFC5322 valid must not imply there are also valid reasons where these messages need not comply with checks for multiple header fields limited to single occurrences. There is no reason to have these checks be an optional configuration as they are in OpenDKIM. In light of conversations by influential individuals that DKIM verifier's role is NOT to make these checks, it therefore becomes essential to clarify the specifics of this particular requirement as a MUST. Skipping these checks invites harm. In addition, these checks have not been defined as the duty of SMTP. Also, the DKIM verifier making this check will not assure RFC5322 compliance, since not reporting a valid signature is to be considered not being signed. The difference is that acceptance based upon trust given a signing domain is not easily exploited when these checks are made by the DKIM verifier. Unfortunately, the norm is not to make these checks because only DKIM invites the possible exploit. DKIM MUST accept the role of preventing the exploit it invites. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Thursday, July 07, 2011 6:47 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review Unfortunately, the norm is not to make these checks because only DKIM invites the possible exploit. DKIM MUST accept the role of preventing the exploit it invites. This is logically equivalent to saying SSL or TLS has to ensure the validity of the payload it is securing, because since that payload has been secured, people will assume it's also valid. Will you be taking your fight to the TLS working group as well, then? Otherwise, this is merely a repetition of the same argument that got us the DISCUSS in the first place. One might even call it a replay attack... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
