Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Monday, October 11, 2010 2:36 AM To: Charles Lindsey; DKIM Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE But it IS a serious protocol endangering problem. No, I don't think so. The protocols are quite clear. rfc5322 section 3.6 says there must be exactly one From: header. If there are two, then you don't have a compliant email. Why any software should assign a positive trust value (like claiming the Author address has been verified) to a non-compliant email, I don't know. Anyway, this is clearly a problem with rfc5322 compliance, not with DKIM. +1 -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Thu, 07 Oct 2010 19:18:19 +0100, Michael Thomas m...@mtcc.com wrote: The larger issue here is would anybody rush out to close this MUST. I think that it is highly unlikely that anybody is going to care at this point. That goes for *any* new MUST, IMO: unless it's really a serious protocol endangering problem, it shouldn't be in the -bis document. Save new MUST's for genuine emergencies. But it IS a serious protocol endangering problem. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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] THIS IS A MULTIPLE 5322.FROM MESSAGE
IMHO, a user who would be fooled by your: From: President Obama ob...@whitehouse.gov From: Hector Santos hsan...@isdg.net would also likely be fooled by: From: President Obama hsan...@isdg.net The latter problem is a hole DKIM just can't plug. At least the dual-From: trick is an easy signature to add to a content filter. By the way, there is no whitehouse.gov ADSP record, so a simple first person forgery of Obama with no trickery would pass today. Although the forger would be wise to use his own MAIL FROM:, as they do have SPF. Being constructive, recommendations such as don't allow multiple From: -- if you really have to then *at least* act on the least favorable ADSP result for each address should probably go into a seperate document, likely a BCP. We could probably fill a document with other recommended techniques an ISP could use to help protect banks from the gullibility of their users, including techniques outside the scope of DKIM. Such as any kind of stab at solving the human-name problem I've highlighted (but that's a huge can of worms), or suppression of attacks using lookalike domains. Michael Deutschmann mich...@talamasca.ocis.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Wed, 06 Oct 2010 18:57:10 +0100, MH Michael Hammer (5304) mham...@ag.com wrote: If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - not our problem? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this. The 5322 people roost on ietf-...@imc.org. But since it is already a REQUIREMENT of 5322 that From, Subject et al should appear no more than once, just what do you suppose they could do beyond what they have already done? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkins st...@wordtothewise.com wrote: On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. No, that is not true, as I have demonstrated in the text I have proposed. You only need to look at whatever headers are actually mentioned in the h= tag of the signature, and you only need to verify those properties of those headers that could lead to trouble, and that would seem to be a simple count of the number of occurrences of those headers. That is actually quite a low bar. Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. The signing domain can only take responsibility for the message it signs. It cannot take responsibility for slightly altered copies of the message that get used in replay attacks. It is DKIM's job to detect such cases, and in the case of the particular scam under discussion it would be quite simple for it to do so. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/07/2010 03:40 AM, Charles Lindsey wrote: On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkinsst...@wordtothewise.com wrote: On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. No, that is not true, as I have demonstrated in the text I have proposed. You only need to look at whatever headers are actually mentioned in the h= tag of the signature, and you only need to verify those properties of those headers that could lead to trouble, and that would seem to be a simple count of the number of occurrences of those headers. I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Michael Thomas wrote: On 10/07/2010 03:40 AM, Charles Lindsey wrote: On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkinsst...@wordtothewise.com wrote: On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. No, that is not true, as I have demonstrated in the text I have proposed. You only need to look at whatever headers are actually mentioned in the h= tag of the signature, and you only need to verify those properties of those headers that could lead to trouble, and that would seem to be a simple count of the number of occurrences of those headers. I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. This is a half full, half empty issue. Lets look at the positive side. DKIM by its very nature has already raised the bar of legacy mail by adding a new level of considerations that mandates certain parts, especially the 5322.From (since its the only requirement for hashing), be valid. We never (afaik) had any technology that does this at the MTA level. DKIM serves that purpose, thus the beauty of it. Before DKIM, RFC5322 has this major problem today. DKIM can leverage this RFC5322 vulnerability by helping address attention to it and close the loophole. It does raise the bar for wannabe DKIM compliant systems to do more than what is normally done. A implicit presumption that mail is RFC5322 compliant is not a safe presumption. The beauty of DKIM is that it moves us away from the legacy system exploits - by raising the email compliancy bar. In that vain this multiple 5322.From issue is directly related to a DKIM purpose to secure it. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Thursday, October 07, 2010 9:09 AM To: Charles Lindsey Cc: DKIM Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? I disagree that it's all that tough. Any DKIM implementation already has to have some code to isolate particular header fields so that they can be replayed in the order h= states, for example. Code to verify there's only one From: (plus the rest of the min/max counts that RFC5322 defines) in that set can't be that expensive. Granted that only covers the chart in section 3.6 of RFC5322, but it would completely handle this problem vector. And there are plenty of open source MTA implementations, the union of which contains a variety of validity checking code that can be used to come up with a valid solution to satisfying the entire RFC. I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. Generally I agree, but does saying verification is undefined satisfy those concerned that this is a security vulnerability? The example of double-From: shows verification succeeds. It's the interpretation of those results that is the problem. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/07/2010 11:01 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Thursday, October 07, 2010 9:09 AM To: Charles Lindsey Cc: DKIM Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? I disagree that it's all that tough. Any DKIM implementation already has to have some code to isolate particular header fields so that they can be replayed in the order h= states, for example. Code to verify there's only one From: (plus the rest of the min/max counts that RFC5322 defines) in that set can't be that expensive. Granted that only covers the chart in section 3.6 of RFC5322, but it would completely handle this problem vector. And there are plenty of open source MTA implementations, the union of which contains a variety of validity checking code that can be used to come up with a valid solution to satisfying the entire RFC. The larger issue here is would anybody rush out to close this MUST. I think that it is highly unlikely that anybody is going to care at this point. That goes for *any* new MUST, IMO: unless it's really a serious protocol endangering problem, it shouldn't be in the -bis document. Save new MUST's for genuine emergencies. I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. Generally I agree, but does saying verification is undefined satisfy those concerned that this is a security vulnerability? The example of double-From: shows verification succeeds. It's the interpretation of those results that is the problem. These are two separate questions, I think. I'm only commenting on whether DKIM should be the SMTP police. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Michael Thomas wrote: Generally I agree, but does saying verification is undefined satisfy those concerned that this is a security vulnerability? The example of double-From: shows verification succeeds. It's the interpretation of those results that is the problem. These are two separate questions, I think. I'm only commenting on whether DKIM should be the SMTP police. I don't think so, but it should inspect its own protocol requirements and within those requirements is its crown jewel - 5322.FROM, the only header that is required binding. Now lets consider if its wasn't a requirement, would it matter then? I think it greatly matters to the MUA participants. Note, the 5322.Subject is also a victim here, but its optional and its security threat is not even close that what a multiple 5322.From reveals. So I think it warrants adding a check for that too. But not as much as the From. The point is DKIM took on the job of providing a mail integrity and authentication work and raised the about what is expected. Included in that job is protecting its primary header - 5322.From. Keep in mind that not protecting it will also hurt ADSP which I already showed that implementation may look for the first one as well. In the spoofed Obama message, this is the authentication results generated here: Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; It picked up the wrong one. So we have TWO protocols that are affected by this. The irony in all this is that this Multiple 5322.From could be used to solve the MLM 3rd party issue. :) The verifier MUST check for invalid 5322.From messages if only because its part of the DKIM and ADSP formula and mechanics. Anyway, I hope the right decision is made and address it before it widely discovered and becomes a problem. Even without DKIM, MTA should be more aware about this and deal with it. But only DKIM can close the loophole for legacy operations. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, October 07, 2010 3:50 AM To: DKIM Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE But since it is already a REQUIREMENT of 5322 that From, Subject et al should appear no more than once, just what do you suppose they could do beyond what they have already done? This seems to support the idea that RFC4871bis simply referring back to RFC5322 to mandate an input requirement is quite sufficient. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
At 10:57 06-10-10, MH Michael Hammer (5304) wrote: the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... hey, this came up in the context of 4871 and we believe That working group did not shut down; it took a pause. At 11:50 06-10-10, Hector Santos wrote: So the 5321/5322 filtering layer approach works fine (but we lose interesting mail g). But I would not have done this if I was not made aware of this problem by Alt-N who discovered this security hole. This case was reported in an implementation several years ago as part of a different issue. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hi SM, -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of SM Sent: Thursday, October 07, 2010 1:02 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE At 10:57 06-10-10, MH Michael Hammer (5304) wrote: the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... hey, this came up in the context of 4871 and we believe That working group did not shut down; it took a pause. Sorry, it was me who told him that. I misunderstood. Even so, as Charles pointed out, I'm not sure exactly what it is we could ask them to change. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hi Murray, At 13:08 07-10-10, Murray S. Kucherawy wrote: Even so, as Charles pointed out, I'm not sure exactly what it is we could ask them to change. RFC 5322 specifies a format for Internet mail. I don't see what could be changed in there as this discussion is not about an issue with the format. You could use the following text: A naive recipient can be tricked if implementations of MUAs and mail filters incorrectly assume that a message that has been successfully verified is RFC 5322 compliant. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/7/2010 4:18 PM, SM wrote: RFC 5322 specifies a format for Internet mail. I don't see what could be changed in there as this discussion is not about an issue with the format. 5321 and 5322 are component specifications, although of course they do have /some/ systems integrative text. But their attention to implementation issues is restricted to the scope of their protocol and format work. One might wish for a broader, systems oriented document that discusses how the components fit together and explains where systems-level and end-to-end issues, such as the one being described here, might get resolved. Darn. That would probably require normative status for such a document. Hmmm. I wonder where the closes approximation might be... 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
Mark Delany wrote: That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. +1. However, the rat hole is when we are not specific and leave it open ended. The proposed text can be: Verifiers MUST make sure only check valid RFC 5322 messages are verified. Specifically verifiers MUST check for multiple 5322.From headers in the message and if found, the verifier MUST invalidate the signature [and reject|discard the message]. If we remain focus with this specific issue on hand - multiple 5322.From, which is critical in the mail infrastructure in every network and is used for every Online or Offline MUA, and today related to DKIM with the required 5322.From hashing, this is one specific invalid mail case that can be easily addressed and doesn't have to be a rat hole nor delay 4871bis progress to draft standard. The funny thing is, I am not even a hacker and I was able to take an archived 5322 message text file, prepend a 5322.From line and resubmit back into the stream with perfect DKIM validity and resigning by another MTA/MLM. It was too easy and I am not smart enough to determine what real hackers can imagine to come up with. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
I've cogitated on this a bit and spoken with a few knowledgeable people. I'm an operations guy and only marginally a standards wonk. So, my belief is that this is really more of a 5322 issue than a 4871 issue. Having said that, I'm not comfortable kicking the can down the road given that what we know, this potentially leads to abuse. If the message is malformed and nonconforming then would it be appropriate to treat the malformed message as no signature? This would be one approach that appears consistent with 4871 yet this grinds on me because it means we are saying that a malformed message with a signature is the same as a conforming signature with no signature. We also have to consider that verifier may be an MTA or an MUA. The implications (operationally) are different for each case. It has also been pointed out to me that a mail implementation may try to fix a malformed message. Regardless of my belief that this is a 5322 issue, my personal preference would be for DKIM verifiers to not validate malformed messages with an outcome of something along the lines of unable to validate due to malformed message. I view this as different than DKIM none. This is perhaps more of an operations perspective. Just a few poorly expressed thoughts and lacking a concrete recommendation that is actionable. Mike -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 06, 2010 1:22 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 05, 2010 8:06 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. ___ 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Mon, 04 Oct 2010 23:24:11 +0100, President Obama ob...@whitehouse.gov wrote: THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE Interestingly, my MUA (Opera) displayed both of those From headers, But I can quite well understand that many other MUAs don't, and even where they do I would expect many phishees would not notice the second one. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Wednesday, October 06, 2010 12:20 AM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE So, my belief is that this is really more of a 5322 issue than a 4871 issue. Having said that, I'm not comfortable kicking the can down the road given that what we know, this potentially leads to abuse. I don't think that's a fair characterization. It is simply wrong to try to deal this problem in DKIM. For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs. There's also a practical difference between software engineering and specification. You'd be justified in deciding to make your MUA code resilient to this problem, but it's wrong for doing so to be mandated by a standards document that has nothing to do with defining the proper format of email. I believe this is a good example of a layering violation. If the message is malformed and nonconforming then would it be appropriate to treat the malformed message as no signature? This would be one approach that appears consistent with 4871 yet this grinds on me because it means we are saying that a malformed message with a signature is the same as a conforming signature with no signature. I understand that concern, but it sounds a lot to me like trying to ascribe a different value to the former case than the latter when we don't know that they deserve different handling. (And that sounds a lot like the unresolved ADSP rathole.) To me, there's a clear boundary between what DKIM defines and what RFC5322 defines. This problem isn't on our side of that line. The RFC5322 part of the code in a verifier should detect and report that the message is malformed, and the DKIM part shouldn't even be invoked. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Mark Delany: That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. +1. This makes more sense to me than trying to enumerate all the possible effects of malformed messages on naive programs. An explicit example may help to motivate the reader (Invalid messages must never verify; for example messages with multiple Subject:, From: or To: header fields). Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. It also changes what DKIM means, operationally, as I know that most email nodes don't check for well-formed emails today rather they parse them with a fairly robust parser. Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. I don't see how adding all that functionality and cost to a DKIM verifier does anything at all to add any value. If anything, it seems it'll just increase the rate at which a DKIM verifier fails to verify a DKIM signature contrary to the expectations of both sender and recipient. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 8:00 AM, Steve Atkins wrote: It also changes what DKIM means, ... Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
I don't think that's a fair characterization. It is simply wrong to try to deal this problem in DKIM. For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs. Yeahbut. Isn't that conflating detection with fixing? Lots of protocols have end-to-end or layer-to-layer verification to detect intervening bugs. You also well know that treating all external input with the greatest suspicion *almost* goes without saying in any programming endeavour, but particularly so in this one. I agree that a full 2822 parser is over the top and something that is unlikely to exist near verification code, but we do need to instruct verifiers to be suspicious and untrusting. What's the middle ground? Serendipitously, my early implementation refused to verify an email that had a From: prior to the signature header. The general problem is that applying authentication results to the whole payload is wrong. I don't argue this, but one could consider removing or denaturing all payload outside of the signature... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Wednesday, October 06, 2010 6:17 AM To: Steve Atkins Cc: DKIM List Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE Recall that the original question was about a valid message with a valid signature, which the attacker mutated by adding an extra header that makes it an invalid message with a signature that still mechanically verifies. Who's responsible for it now? Is it DKIM's job to make the verification fail, or is it an MUA's job to do something reasonable with malformed messages? Yeah, this just occurred to me as well. Any application (signer/verifier, spam filter, MLM, user agent, whatever, even if it has nothing to do with DKIM) that bases its actions on header fields but doesn't check for valid format first may have this vulnerability in some form. For example, an MLM that authenticates a poster based on one From: field while MUAs might render a different one has the very same problem. Trying to deal with this in 4871bis almost seems pointless when the issue is scaled that far. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 9:17 AM, John R. Levine wrote: Is it DKIM's job to make the verification fail, or is it an MUA's job to do something reasonable with malformed messages? At one level, that's merely an implementation choice. At another level, it is a question of whether conformance enforcement MUST occur at all. The discussions have tended to assume that it MUST occur, by virtue of the DKIM requirement for 'conformant' messages. Steve's point cleverly suggests that DKIM itself can dodge the issue by -- once again -- having things simply rest on verification outcome. I find the simplicity and sufficiency of Steve's point pretty darn appealing. To emphasize: It's sufficient because it focuses on DKIM's actual goal and does not expand that scope. 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, October 06, 2010 7:02 AM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE I find the simplicity and sufficiency of Steve's point pretty darn appealing. To emphasize: It's sufficient because it focuses on DKIM's actual goal and does not expand that scope. Can we get some proposed text? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Wed, Oct 6, 2010 at 9:15 AM, Dave CROCKER d...@dcrocker.net wrote: On 10/6/2010 8:00 AM, Steve Atkins wrote: It also changes what DKIM means, ... Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. If you put back this piece of what Steve said: To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. Do you come to the same conclusion? Steve, do you agree with Dave's conclusion? -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Apologies all for top posting. Having to use a different client due to technical difficulties. Murray, I'm violently agreeing with you that it is not strictly speaking a 4871 issue. Having said that, I believe that it is an issue that begs the question... where should it land? You are correct that this is the difference between implementation and standards. Either way, we need to look at the outcomes of what we do. I'm agreeing with you that IETF-DKIM may not be the place to address it...assuming there is a beleif that it is a problem at all. So the first question is whether this is a problem, if the consensus is that it isn't a problem, great...nothing more need be done. If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - not our problem? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this. Mike -Original Message- From: ietf-dkim-boun...@mipassoc.org on behalf of Murray S. Kucherawy Sent: Wed 10/6/2010 8:13 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE -Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Wednesday, October 06, 2010 12:20 AM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE So, my belief is that this is really more of a 5322 issue than a 4871 issue. Having said that, I'm not comfortable kicking the can down the road given that what we know, this potentially leads to abuse. I don't think that's a fair characterization. It is simply wrong to try to deal this problem in DKIM. For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs. There's also a practical difference between software engineering and specification. You'd be justified in deciding to make your MUA code resilient to this problem, but it's wrong for doing so to be mandated by a standards document that has nothing to do with defining the proper format of email. I believe this is a good example of a layering violation. If the message is malformed and nonconforming then would it be appropriate to treat the malformed message as no signature? This would be one approach that appears consistent with 4871 yet this grinds on me because it means we are saying that a malformed message with a signature is the same as a conforming signature with no signature. I understand that concern, but it sounds a lot to me like trying to ascribe a different value to the former case than the latter when we don't know that they deserve different handling. (And that sounds a lot like the unresolved ADSP rathole.) To me, there's a clear boundary between what DKIM defines and what RFC5322 defines. This problem isn't on our side of that line. The RFC5322 part of the code in a verifier should detect and report that the message is malformed, and the DKIM part shouldn't even be invoked. ___ 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 1:22 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 05, 2010 8:06 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. +1 I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Charles Lindsey wrote: On Mon, 04 Oct 2010 23:24:11 +0100, President Obama ob...@whitehouse.gov wrote: THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE Interestingly, my MUA (Opera) displayed both of those From headers, But I can quite well understand that many other MUAs don't, and even where they do I would expect many phishees would not notice the second one. Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; And for ADSP, our verifier picked up the first (top) 5322.From domain as well. Since I whitelist mipassoc.org, I get all its output. Mind you, that I had to do this twice to get a copy because I had already added a multiple 5322.From rejector script at the SMTP DATA session. I had to turn it off and repeat it to get a copy that I see here from spoofed President Obama. So the 5321/5322 filtering layer approach works fine (but we lose interesting mail g). But I would not have done this if I was not made aware of this problem by Alt-N who discovered this security hole. And that is the main gist of this, and I don't care how the IETF cats wants to do this: Engineering AWARENESS must be added to the 4871bis. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Dave CROCKER d...@dcrocker.net wrote: On 10/6/2010 8:00 AM, Steve Atkins wrote: It also changes what DKIM means, ... Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with It's not valid 5322, so it can't be valid DKIM, it puts the question of how implementors should deal with such things back on the table. I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 3:01 PM, Scott Kitterman wrote: Dave CROCKER d...@dcrocker.net wrote: On 10/6/2010 8:00 AM, Steve Atkins wrote: It also changes what DKIM means, ... Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with It's not valid 5322, so it can't be valid DKIM, it puts the question of how implementors should deal with such things back on the table. They can deal with it however they like - but as far as the DKIM validator is concerned there's either a valid DKIM signature, or there isn't, so it's the associated code (where DKIM plugs into the rest of the mail handling engine) that'll need to be aware of it. Were I writing the signer, though, or the code surrounding the validator I'd appreciate some mention of this gotcha in the spec so I know I need to deal with it. I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. +1 The more helpful the spec can be to implementors, the better, and this is a grubby corner. Maybe this is an added item for security considerations? Likely, yes. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Dave CROCKER d...@dcrocker.net wrote: In particular, it makes the multiple From: issue entirely irrelevant to DKIM. Scott Kitterman wrote: In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with It's not valid 5322, so it can't be valid DKIM, it puts the question of how implementors should deal with such things back on the table. +1 I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations? +1. This is where I thought it would go. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 1:57 PM, MH Michael Hammer (5304) wrote: Apologies all for top posting. Having to use a different client due to technical difficulties. Murray, I'm violently agreeing with you that it is not strictly speaking a 4871 issue. Having said that, I believe that it is an issue that begs the question... where should it land? You are correct that this is the difference between implementation and standards. Either way, we need to look at the outcomes of what we do. I'm agreeing with you that IETF-DKIM may not be the place to address it...assuming there is a beleif that it is a problem at all. So the first question is whether this is a problem, if the consensus is that it isn't a problem, great...nothing more need be done. If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - not our problem? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this. One possibility is in a bis version of the Development, Deployment and Operations document. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. For example: From: phis...@badguy.com-- injected, replayed, shown by MUA DKIM-Signature: d=signer.com ...; From: sig...@address.com-- hash bound to signature The MUA will display the injected 5322.From header and the signature is still valid because it only signed the bottom one and verifiers also use this header to validate the signature. A review of the the 4871 specification shows this statement in section 5.4 which can explains how this is possible: 5.4. Determine the Header Fields to Sign ... Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. There needs to be a special consideration where: 1) Verifiers and MDAs consider checking for violating RFC5322 messages with multiple 5322.From headers and rejected it, or 1) hash verification should be done for all 5322.From fields and not just the last one as the above paragraph implies. 2) signing should be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
President Obama wrote: [...] Funny, but this shows nothing because mipassoc.org resigns messages (d=mipassoc.org). (Oh, and it even included *two* Froms in h= on your message.) I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -1. Why do you insist on changing the hashing semantics to special-case From? Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: President Obama wrote: [...] Funny, but this shows nothing because mipassoc.org resigns messages (d=mipassoc.org). (Oh, and it even included *two* Froms in h= on your message.) Right. Does this add signer reputation weight for the injected 5322.From? Not good. If mipassoc.org is being vouched by some 3rd party reputation service. The user sees a signed valid message possibly vouched by trusted service with a signature hash bound spoofed 5322.From. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -1. Why do you insist on changing the hashing semantics to special-case From? Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Not proposing a to change the semantics. But rather to add insight about the issue so that implementators can deal with it. For example, when I received the echo back from the list, my MTA rejected it. 18:46:07 C: MAIL From:ietf-dkim-boun...@mipassoc.org SIZE=5329 18:46:07 S: 250 ietf-dkim-boun...@mipassoc.org 18:46:07 C: RCPT To:hsan...@isdg.net 18:46:08 S: 250 hsan...@isdg.net... Recipient ok 18:46:08 C: DATA 18:46:08 S: 354 Start mail input; end with CRLF.CRLF 18:46:08 ** end of data received. (bytes: 5738) 18:46:08 ** WCX Process: SmtpFilterHookLoader ret: 0 18:46:08 ** Invalid 5322 Message - multiple From: headers not allowed 18:46:08 S: 551 Message Not Accepted by filter. 18:46:10 C: QUIT 18:46:10 S: 221 closing connection Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. However, if you are suggesting that it needs to be explicitly defined to mitigate this problem, then the specs needs to be updated to address the security issues. The fact, Mipassoc.org, stripped my original header and signed with the double from: lines, one real, one an injected spoofed, proves exactly what the problem here is. I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hector Santos wrote: Right. Does this add signer reputation weight for the injected 5322.From? Probably not. AFAICT mipassoc.org doesn't verify DKIM sigs on list messages, and even if it did, a verified DKIM sig (such as one created by the original author of the message) doesn't tell anything about the legitimacy of the use of the From identity. Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. No. h= must not be empty. The spec explicitly forbids this. Cf. http://tools.ietf.org/html/rfc4871#page-20 h= [...] This list MUST NOT be empty. [...] As for a possible change in RFC 4871bis, if you look at page 41 of 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: | INFORMATIVE NOTE: A header field name need only be listed once | more than the actual number of that header field in a message at | the time of signing in order to prevent any further additions. | For example, if there is a single Comments header field at the | time of signing, listing Comments twice in the h= tag is | sufficient to prevent any number of Comments header fields from | being appended; it is not necessary (but is legal) to list | Comments three or more times in the h= tag. I suggest replacing Comments with From. That should solve the problem. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Again, please don't CC me. I'm subscribed to the list. Stephen Farrell wrote: On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. Yeah, possibly. I wasn't even thinking of using RFC 2119 verbiage. As I've written in my previous mail I think there's a better way to solve this (non-)issue. Just s/Comments/From/ in that INFORMATIVE NOTE on page 41 of 4871bis-01. What do you think? -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hector Santos wrote: I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? For the records, from my gmail testing, it will spambox the RFC 5322 message with one or more 5322 lines. But it also does one other thing - it removes ALL the headers and recreates its own with no subject. It doesn't matter if its signed or not. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: Hector Santos wrote: Right. Does this add signer reputation weight for the injected 5322.From? Probably not. How do you know what the heuristic systems are doing? AFAICT mipassoc.org doesn't verify DKIM sigs on list messages, it does. It verifies, adds an Authentication-Results: header, strip the original signature, add a fooder and a [list] to the subject and resigns. and even if it did, a verified DKIM sig (such as one created by the original author of the message) doesn't tell anything about the legitimacy of the use of the From identity. Not sure what that means Julian. Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. No. h= must not be empty. The spec explicitly forbids this. You misunderstood. What that means is that the signing function MUST add a h= to the 5322.DKIM-Signature line for the 5322.headers it decides to hash and bind to the signature. The operators with their DKIM implementation can set what headers to sign or they can choose NOTHING and allow the default behavior for the implementation. In other words, the operator can set (in whatever way the software does it): RequiredHeaders From:To:Date:Message-Id:Organization:Subject Now the signing engine will follow this. If not set, then it has its own default rules. The recommendation is presented in RFC 4871. What you are suggestion is that implementation had their defautlt to include From:From, like above: RequiredHeaders From:From:To:Date:Message-Id:Organization:Subject As for a possible change in RFC 4871bis, if you look at page 41 of 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: | INFORMATIVE NOTE: A header field name need only be listed once | more than the actual number of that header field in a message at | the time of signing in order to prevent any further additions. | For example, if there is a single Comments header field at the | time of signing, listing Comments twice in the h= tag is | sufficient to prevent any number of Comments header fields from | being appended; it is not necessary (but is legal) to list | Comments three or more times in the h= tag. I suggest replacing Comments with From. That should solve the problem. I did notice this too and thought the same idea. :) What the specs need in whatever IETF method you guys like to do things: 1) Semantics that DKIM-compliant MTA doing stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. 3) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. One could argue that this'd be a material change to the protocol that is not a deletion, and hence that deployed code would have to change to comply, which, to me, goes against at least the spirit of the PS-DS transition. (Which is the point of the current exercise.) So in terms of meeting our chartered goals, this specific addition might have undesirable side effects were it to represent the WG's opinion. (Much as the chairs love you all, starting right in on a 4871ter is not attractive:-) Stephen. PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Stephen Farrell wrote: On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. So in terms of meeting our chartered goals, this specific addition might have undesirable side effects were it to represent the WG's opinion. (Much as the chairs love you all, starting right in on a 4871ter is not attractive:-) To address current implementations, guidelines should be considered: 1) Suggest MTA do stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. 3) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. #1 is words and a remember for MTA especially those that are with a DKIM environment to tighten up there wares. #2 can be done with current implementation operators. I am assuming all or not most of DKIM signing engines will allow operators to set Required Headers to sign. It would be rather inflexible if it did not. #3 is already done by at least one open source DKIM API developed by a large MTA vendor. Not sure how OpenDKIM is will do it, but Murray did speak of the layer (#1) approach. #1 and #2 will allow most implementations to close this loophole until software vendors catch up with #3. That said, I don't think writing #1, #2 or #3 text for 4871bis should slow down progress to draft standard. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. FWIW: Adding to a specification, by trying to protect against behavior that is already illegal is wasteful, redundant and opens the door to an infinite path of similarly unnecessary provisions. Plainly bad specification methodology. 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Tue, Oct 05, 2010 at 10:31:32PM -0400, Dave CROCKER allegedly wrote: PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. FWIW: Adding to a specification, by trying to protect against behavior that is already illegal is wasteful, redundant and opens the door to an infinite path of similarly unnecessary provisions. Plainly bad specification methodology. Right. This seems like it's going down a rat-hole. There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 05, 2010 8:06 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hi Stephen, At 16:46 05-10-10, Stephen Farrell wrote: Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. Such a change may affect the progress to draft standard. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
