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] New Version Notification for draft-ietf-dkim-mailinglists-03
On Wed, 06 Oct 2010 13:23:49 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 06, 2010 4:36 AM To: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03 Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. You can define the architecture so that the discarding is done by (or close to) the verifier, or that it is done by a separate agent (the receiver). I don't mind either way, but you need to be consistent. Currently, the wording of 5.10 suggests that you are using the second model (the verifier leaves it alone and the receiver looks at the verifification results in the A-R header and decides whether or not to actually discard). The change you have made in response to Dave is an improvement (it solves my immediate problem), but it still leaves in doubt which of the two models you are using. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. The first paragraph describes a pro of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a con (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a pro of removing them, etc. Well the title was Pros and Cons of ... Removal, so the first paragraph is actually a Con of removal for the case where a signature might still be valid. There is no dispute about that. And then the second paragraph is a Pro for removal in the case where the signature has been invalidated. But what is missing is any Con for removal in the invalidated case (e.g. keeping it for forensic use). Actually, a suggestion to replace the removed signature with an X-Original-Signature would be quite sufficient for forensic purposes. Wuld you be willing to add a suggestion to possibly do that? That second paragraph didn't read like a Con to me. In fact it seems like a further Pro insofar as it recommends a further action which turns out to be -- 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
[ietf-dkim] Fwd: Re: THIS IS A MULTIPLE 5322.FROM MESSAGE
On Wed, 06 Oct 2010 13:01:29 +0100, Wietse Venema wie...@porcupine.org wrote: Mark Delany: 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). s/must/MUST/, and then +1 -- 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 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] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
On Wed, 06 Oct 2010 13:25:28 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 06, 2010 3:47 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From And note that pious exhortations to ensure that RFC5322 be followed, or that MUAs should be fixed to solve this problem, are no solution. We live in the Real World (TM), and neither of those things is going to happen, desirable as they might be. If we can't rely on people to provide valid input when admonished to do so, then there's no point in continuing any of this work. Well it is a plain fact that lots of mail non conforming to RFC 5322 is floating around, and nearly all MUAs are accepting it on the grounds of being liberal in what they accept. So it is clear that we cannot rely on people as you suggest. And for sure you cannot expect phishers to heed any admonishments whatsoever. And yet we must develop systems that are secure in spite of all that. -- 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] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
-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:29 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From If we can't rely on people to provide valid input when admonished to do so, then there's no point in continuing any of this work. Well it is a plain fact that lots of mail non conforming to RFC 5322 is floating around, and nearly all MUAs are accepting it on the grounds of being liberal in what they accept. So it is clear that we cannot rely on people as you suggest. And for sure you cannot expect phishers to heed any admonishments whatsoever. And yet we must develop systems that are secure in spite of all that. Any implementer must understand that be liberal in what you accept is not carte blanche to weaken parsing strictness in arbitrary ways just to make things easier on the user (or to satisfy a laziness quota). Every such choice introduces risk. There's a difference between a what specification can mandate in order for an implementation to be compliant with it, and what people actually do. We can say MUST until we're blue in the face but there's no way to compel implementers to stick to every aspect of a specification other than to expose them to the risks of not doing so. They simply lose the badge of saying they're compliant. As you say, a lot of people are probably okay with that until it stings them somehow. This has been a vector for spoofing users via MUAs for a long time because a message with two From: fields may still render the wrong one when, say, a greylist or spam filter has acted on the right one (whatever those terms might mean). This was true even before DomainKeys or SPF happened along, so it's not strictly a DKIM issue. That From is a special case for DKIM merely because its signing is required doesn't change that fact. As another data point, RFC4407 (the PRA portion of Sender ID) also declared that a multiple-From message could not be considered to have a valid Purported Responsible Address, and so Sender ID cannot execute on such a message because there is no input to its algorithm. And I do not buy the argument that DKIM is the right place to fix this just because it's the most recent email RFC that email people might read. Maybe we need a Be Liberal In What You Accept Considered Harmful document. ___ 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] New Version Notification for draft-ietf-dkim-mailinglists-03
-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:03 AM To: DKIM Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03 You can define the architecture so that the discarding is done by (or close to) the verifier, or that it is done by a separate agent (the receiver). I don't mind either way, but you need to be consistent. Currently, the wording of 5.10 suggests that you are using the second model (the verifier leaves it alone and the receiver looks at the verifification results in the A-R header and decides whether or not to actually discard). The change you have made in response to Dave is an improvement (it solves my immediate problem), but it still leaves in doubt which of the two models you are using. I'll review it. Really, though, rejection in some form (bounce, drop, spam-folder) can take place at either location, so maybe it's best to fall back to something more generic and say a module can reject instead of naming one or the other specifically. ___ 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] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/7/2010 1:00 PM, Murray S. Kucherawy wrote: so maybe it's best to fall back to something more generic and say a module can reject instead of naming one or the other specifically. +1 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 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] detecting header mutations after signing
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. Except that's not the situation we have here. a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone d) Receiver receives it and, uh, well, what? Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. As far as I can tell, this problem, detecting header changes, is a security problem that has never come up before. PGP, S/MIME, and PEM only protect the body, in some cases by wrapping the entire message as a message/rfc822 MIME body part and signing that. RFC 2822 and its predecessors tell you what is a valid message, but say approximately nothing about invalid messages other than a few historically motivated notes like bare linefeeds really are invalid. I think I can safely say that there is no chance at all that Pete Resnick et al. would agree to change 2822bis to fix holes in DKIM. I'm scratching my head to see if there is any advice we can offer to make signing and verification more robust while not changing the behavior of existing code for normal (for some definition of normal messages). A) You have to sign either all occurences of a header or none of them, and a message with some but not all occurences signed fails verification. This is probably too strong, although I doubt that there are many places in practice where it would matter. B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/07/2010 05:01 PM, John R. Levine wrote: 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. Except that's not the situation we have here. a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone d) Receiver receives it and, uh, well, what? Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. You're right, it does miss the point. What I'm trying to get my head around is whether this is a real problem in the real world. Any reasonable spam filter would notice evil double From:'s in a New York minute, so I can't get particularly worked up about this being some sort of existential threat. Can someone come up with a scenario where this really could be evil and isn't trivially fixed by... making spam filters insist that they're really receiving valid 5322 as one of their rules? Mike, I only have vague recollection of the h= trick anymore... As far as I can tell, this problem, detecting header changes, is a security problem that has never come up before. PGP, S/MIME, and PEM only protect the body, in some cases by wrapping the entire message as a message/rfc822 MIME body part and signing that. RFC 2822 and its predecessors tell you what is a valid message, but say approximately nothing about invalid messages other than a few historically motivated notes like bare linefeeds really are invalid. I think I can safely say that there is no chance at all that Pete Resnick et al. would agree to change 2822bis to fix holes in DKIM. I'm scratching my head to see if there is any advice we can offer to make signing and verification more robust while not changing the behavior of existing code for normal (for some definition of normal messages). A) You have to sign either all occurences of a header or none of them, and a message with some but not all occurences signed fails verification. This is probably too strong, although I doubt that there are many places in practice where it would matter. B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. R's, John ___ 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] detecting header mutations after signing
this being some sort of existential threat. Can someone come up with a scenario where this really could be evil and isn't trivially fixed by... making spam filters insist that they're really receiving valid 5322 as one of their rules? If one does real whitelisting based on valid signature from senders known to be well behaved, it would be a pain if we had to run everything through spamassassin anyway. Mike, I only have vague recollection of the h= trick anymore... You list all the headers you sign in h= list, and you can include headers that don't exist, which means that they can't exist when verified either. So for a header that occurs N times, you can list it N+1 times in h= to ensure that more aren't added. The original motivation was usually N=0 to avoid games played by adding MIME headers to messages that don't have them, but it's generally applicable. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
I'm scratching my head to see if there is any advice we can offer to make signing and verification more robust while not changing the behavior of existing code for normal (for some definition of normal messages). A) You have to sign either all occurences of a header or none of them, and a message with some but not all occurences signed fails verification. This is probably too strong, although I doubt that there are many places in practice where it would matter. B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. That raise a pre-cursor question as to whether DKIM is intended to offer rendered-to-user value? If not, then this whole discussion is moot. If so, then that implies greater participation from the rendering process. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
