Re: [ietf-dkim] Pete's review of 4871bis
On 6/29/11 11:49 AM, Pete Resnick wrote: On 6/29/11 11:20 AM, Charles Lindsey wrote: I agree that 8.14 is poorly written (and it was even worse a while back). However, there most certainly IS an attack here, which is NOT the same as the related attack discussed in 8.15, and cannot be prevented by putting extra entries in the 'h=' tag. Unfortunately, many WG members have failed to understand the difference between the two. Here is the attack, described in plain terms: A phisher obtains a throwaway domain and creates a public/private key pair for it. He then sends messages of the following form: To: some.sucker@anywhere.example From: eBaye...@ebay.co.uk Date: Tue, 17 May 2011 13:21:06 +0100 Subject: Some plausible Ebay subject Lots of other normal headers From: a.phisher@mythrowayawdomain.example DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example; h=from:to:subject:date; ... b=valid signature Body of message of typical Phish style. - A compliant DKIM verifier will report that as a validly signed message. The second From field is absolutely irrelevant in the example. The phisher could simply leave out the From field with their address in it and sign the ebay From field. And that's not an attack. The signer signed the message and the signature verifies. *DKIM* has done its job successfully and has not been attacked. DKIM communicates from the signer to the verifier. The signer *can't* attack itself. You *might* characterize this as an attack against 5322 (in that From addresses are not bound in any secure way to the actual author), but DKIM does not even attempt to address that attack, so it's not an attack against DKIM. You go on to say something that is an attack, but again you get the analysis wrong: The Ebay signature is irrelevant for the signing process (so even if Ebay has declared a Discardable ADSP policy it will not be invoked). Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack on ADSP. If ADSP sees the above message and doesn't discard it, then ADSP has done the wrong thing. If ADSP has a bug where it thinks it ought not discard the above message (with the appropriate policy), then that should be fixed. It should certainly be called out in the security considerations of ADSP. But it's NOT a security consideration for DKIM. This is a poor example of a potential problem. The problem may occur whenever email acceptance is predicated upon the signing domain. When this domain is of sufficient volume where this domain constrains the From to being within the same domain or verified by a ping-back, on that basis their messages should be safe to accept. However when pre-pended From header fields are not precluded from producing valid signatures, (a silent condition) acceptance on the basis of a high volume signature would not be safe, whether or not ADSP is applied. Normal readers using current MUAs will see just the From: Ebay header and, believing that their ISP has done some magical cryptographic checks to prevent bogus Ebay messages from getting through, will be reassured. Again, the second From is not required for that to happen. If MUAs believe that some magical crypto thing happens to a message with d=badguy.example and From: ebay (with no other From's), then they get what they paid for. Agreed. But then this would not be basing acceptance on the signing domain. The present draft does make some woolly attempts to fix this problem. Section 3.8 says verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322] ... . But gives no guidance as to what reasonable means (and full RFC5322 compliance checking is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves it to the implelemtor to work out what he needs to do. As this conversation has developed (here and off line), I'm getting convinced that 3.8 is a red herring. DKIM deals perfectly well with the obsolete message format, including multiple From fields. I think the 3.8 admonition is overblown. In my opinion, there needs to be some REQUIRED action in the verifier which will result in a PERMFAIL, and which would then catch all attacks of this nature. But the WG consensus has been against this. If the WG is against it, it is correct. This is NOT a PERMFAIL condition for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a different document. So much for safe incremental deployment. :^( -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On 6/30/11 9:53 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, June 30, 2011 7:05 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis The problem is that an apparently valid signature (albeit atching the wrong From) is likely to give a false impression of validity somewhere along the line unless modules down the line are watchig for this case (and for sure MUAs will not be watching for it for a long time, so it is the ISPs/boundary agents that need to do it). If the advent of DKIM means that numerous modules implementing other specifications loosely suddenly have to pay a price for doing so, then that's the reality, and I still don't see how that's a problem DKIM needs to fix. Sure, we need to document the nuances DKIM introduces, but it's still not an attack against DKIM, so this remains the wrong place to deal with it in a normative sense. If you prefer the loose application of other standards, don't use DKIM (and lose out on its benefits). Murray, DKIM is not enforcing RFC5322's format. Nor is it reasonable to expect that SMTP has either. It is reasonable to expect security related protocols validate input. Whether a message gets rejected or dropped is immaterial. For DKIM's output to be usable, it must be clear what was signed without expecting subsequent message handlers to adopt bottom-up selection. Otherwise, DKIM can not be safely deployed in an incremental fashion as claimed in its introduction. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On Wed, 29 Jun 2011 19:49:27 +0100, Pete Resnick presn...@qualcomm.com wrote: On 6/29/11 11:20 AM, Charles Lindsey wrote: A phisher obtains a throwaway domain and creates a public/private key pair for it. He then sends messages of the following form: To: some.sucker@anywhere.example From: eBaye...@ebay.co.uk Date: Tue, 17 May 2011 13:21:06 +0100 Subject: Some plausible Ebay subject Lots of other normal headers From: a.phisher@mythrowayawdomain.example DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example; h=from:to:subject:date; ... b=valid signature Body of message of typical Phish style. - A compliant DKIM verifier will report that as a validly signed message. The second From field is absolutely irrelevant in the example. The phisher could simply leave out the From field with their address in it and sign the ebay From field. But not with Ebay's private key, and that would surely get spotted (with or without ADSP). And that's not an attack. The signer signed the message and the signature verifies. *DKIM* has done its job successfully and has not been attacked. DKIM communicates from the signer to the verifier. The signer *can't* attack itself. Sure, but this is an attack directed against Ebay. If the signer succeeds in fooling both the verifier/policy module/whatever else the ISP provides, and thereby in fooling the ultimate recipient, then something has gone badly wrong. The ultimate recipient is not interested in arcane details of who has attacked whom, or who was responsible, or which RFC has been broken; he just discovers that he has been fooled (and his pocket emptied), and all he can see is that the people who were supposed to protect him are busy passing the buck amongst themselves. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On Wed, 29 Jun 2011 18:31:04 +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, June 29, 2011 9:20 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis I agree that 8.14 is poorly written (and it was even worse a while back). However, there most certainly IS an attack here, which is NOT the same as the related attack discussed in 8.15, and cannot be prevented by putting extra entries in the 'h=' tag. Unfortunately, many WG members have failed to understand the difference between the two. That's a mischaracterization of the objection. h=from:from:... was not meant to address the attack about which you are complaining. True, but up to a couple of months ago that was not clear in 8.14/8.15, and I suspect some WG members still have not caught up with the distinction. Nobody has said either of the two variants of this attack are not valid concerns. The dispute is about what module in the handling of a message is responsible for detecting and dealing with it. That is true enough, but there is no indication anywhere as to what subsequent modules in the chain ARE to be responsible for it, axcept for ADSP (and I agree with Pete that it is an attack on ADSP); but the WG seems to have washed its hands of ADSP. Since the problem exists even with a message that is not DKIM-signed, I still fail to understand how this is specifically a DKIM problem. The problem is that an apparently valid signature (albeit atching the wrong From) is likely to give a false impression of validity somewhere along the line unless modules down the line are watchig for this case (and for sure MUAs will not be watching for it for a long time, so it is the ISPs/boundary agents that need to do it). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, June 30, 2011 7:05 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis The problem is that an apparently valid signature (albeit atching the wrong From) is likely to give a false impression of validity somewhere along the line unless modules down the line are watchig for this case (and for sure MUAs will not be watching for it for a long time, so it is the ISPs/boundary agents that need to do it). If the advent of DKIM means that numerous modules implementing other specifications loosely suddenly have to pay a price for doing so, then that's the reality, and I still don't see how that's a problem DKIM needs to fix. Sure, we need to document the nuances DKIM introduces, but it's still not an attack against DKIM, so this remains the wrong place to deal with it in a normative sense. If you prefer the loose application of other standards, don't use DKIM (and lose out on its benefits). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
Pete: I'll mostly let the editors reply to this, but there are a couple of things I want to say first. The first thing is that it's out of scope to address changes to things that were in RFC 4871, which was approved by the working group, the community, and the IESG in 2007, if it's simply a question of one or two people not liking those things so much -- even if one or two of those people now sit on the IESG. The working group has really made an effort to avoid casual changes, and I support that, as chair and document shepherd. 1. I find the use of the word INFORMATIVE throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose. This is one category of those things that appeared in 4871. I also strongly disagree that they serve no purpose. It's useful to make it clear when we have informative text that readers might misunderstand to be normative. In any case, it's harmless, even if you don't like it for stylistic reasons. But the bottom line is that these were there before, and should stay there now... except, of course, for removing or changing ones that are wrong or truly unclear. 4. Section 3.4.4: INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude ASCII Art attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the simple body canonicalization algorithm should be used instead. This is not an attack, or at the very least it is not an attack on DKIM. You can play this same game with MIME encodings or other textual tricks. I don't see any justification for this note being in this document. It's a very weak attack, and might be something we shouldn't bother mentioning, but it is an attack, and one that the working group decided to put into 4871. One thing that DKIM ensures is that someone can't put, say, a line that says viagra into the middle of an otherwise legitimate message without invalidating the signature. But with relaxed body canonicalization, an attacker can insert and remove spaces at will, wherever there's already a space, and that can be used to create the word viagra in ASCII art, though quite crudely. Personally, I think it's a silly thing to worry about, and that we shouldn't mention it. But it's not up to me: it has working group consensus from before RFC 4871 was published. 5. Section 3.4.5: INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria. I don't understand how this is an attack. If the signer said, I'm signing the first n bytes of the body of this message and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. Of course, that's why it's an informative implementation note. You're saying that it's not worth pointing out pitfalls, and that we should stick to the facts of the protocol. Maybe. Maybe this should be in the informative documents, the overview and the deployment guide. Maybe several of the similar items should. The working group chose to put it into RFC 4871 instead. It's worth noting that this is warning about a tag that the working group considers VERY problematic, and that the WG thought hard about removing in the progression to DS. In the end, we did not have consensus to remove it. We do have consensus to leave in the warnings. 10. Section 3.5, h=: INFORMATIVE EXPLANATION: The exclusion of the header field name and colon as well as the header field value for non-existent header fields allows detection of an attacker that inserts an actual header field with a null value. I cannot parse that sentence. I have no idea what it means. It's a horrible sentence, and needs rewording (or removal). But I know what it means. When you sign an empty header field (like Floob:), you are signing the field name (floob), the colon, and the terminating CRLF (with a null value). When you sign a header field that doesn't exist in the message, you are signing a complete null string: a null field name, and a null (absent) colon, value, and CRLF. This is trying to point out the difference, and is
Re: [ietf-dkim] Pete's review of 4871bis
On Wed, 29 Jun 2011 05:46:06 +0100, Pete Resnick presn...@qualcomm.com wrote: 32. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., h=...:from:from:... on messages with one From: header field are leaving themselves open to this attack. The attack is not on the verifier. Additionally: Note that the technique for using h=...:from:from:..., described in Section 8.15 below, is of no effect in the case of an attacker that is also the signer. That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier. Section 8.14 needs to be completely rewritten. It is nonsensical as it stands. I agree that 8.14 is poorly written (and it was even worse a while back). However, there most certainly IS an attack here, which is NOT the same as the related attack discussed in 8.15, and cannot be prevented by putting extra entries in the 'h=' tag. Unfortunately, many WG members have failed to understand the difference between the two. Here is the attack, described in plain terms: A phisher obtains a throwaway domain and creates a public/private key pair for it. He then sends messages of the following form: To: some.sucker@anywhere.example From: eBay e...@ebay.co.uk Date: Tue, 17 May 2011 13:21:06 +0100 Subject: Some plausible Ebay subject Lots of other normal headers From: a.phisher@mythrowayawdomain.example DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example; h=from:to:subject:date; ... b=valid signature Body of message of typical Phish style. - A compliant DKIM verifier will report that as a validly signed message. The Ebay signature is irrelevant for the signing process (so even if Ebay has declared a Discardable ADSP policy it will not be invoked). Normal readers using current MUAs will see just the From: Ebay header and, believing that their ISP has done some magical cryptographic checks to prevent bogus Ebay messages from getting through, will be reassured. The present draft does make some woolly attempts to fix this problem. Section 3.8 says verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322] ... . But gives no guidance as to what reasonable means (and full RFC5322 compliance checking is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves it to the implelemtor to work out what he needs to do. In my opinion, there needs to be some REQUIRED action in the verifier which will result in a PERMFAIL, and which would then catch all attacks of this nature. But the WG consensus has been against this. There are clearly related attacks, possibly involving duplications of other headers (including some MIME headers), and there are similar attacks involving replays and men-in-the-middle and which are covered under 8.15. But the one I have shown is the real killer IMHO. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
to create the word viagra in ASCII art, though quite crudely. So I don't understand. You're saying that a MITM can insert and delete spaces freely, so they're going to be able to change my text to make it appear that it has a different message? That would be an attack, but rather insane. Yes, exactly. It's talking about a mitm inserting spaces freely into a signed message. And, yes, it's quite insane. b ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On 6/29/11 11:11 AM, Barry Leiba wrote: Pete: I'll mostly let the editors reply to this, but there are a couple of things I want to say first. The first thing is that it's out of scope to address changes to things that were in RFC 4871, which was approved by the working group, the community, and the IESG in 2007, if it's simply a question of one or two people not liking those things so much -- even if one or two of those people now sit on the IESG. The working group has really made an effort to avoid casual changes, and I support that, as chair and document shepherd. Yup, absolutely agreed. As I said, I do need to sort these comments into serious, I hope the WG looks at, and Pete makes a comment that can be ignored. I didn't want to spring this long list on folks Thursday morning and not at least give people a chance to digest them. I'll work today on that list. 1. I find the use of the word INFORMATIVE throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose. This is one category of those things that appeared in 4871. Yes. Definitely in the category of Pete makes a comment that can be ignored. If the WG finds that implementation of 4871 was not hindered by this, and it wasn't added without consideration, so be it. I hold my nose and put up with it. I also strongly disagree that they serve no purpose. Bar BOF to be arranged on the INFORMATIVE/NORMATIVE verbal tick that has developed in the IETF. 4. Section 3.4.4: INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude ASCII Art attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the simple body canonicalization algorithm should be used instead. This is not an attack, or at the very least it is not an attack on DKIM. You can play this same game with MIME encodings or other textual tricks. I don't see any justification for this note being in this document. It's a very weak attack, and might be something we shouldn't bother mentioning, but it is an attack, and one that the working group decided to put into 4871. One thing that DKIM ensures is that someone can't put, say, a line that says viagra into the middle of an otherwise legitimate message without invalidating the signature. But with relaxed body canonicalization, an attacker can insert and remove spaces at will, wherever there's already a space, and that can be used to create the word viagra in ASCII art, though quite crudely. So I don't understand. You're saying that a MITM can insert and delete spaces freely, so they're going to be able to change my text to make it appear that it has a different message? That would be an attack, but rather insane. I *suspect* that what this really means is that the *signer* can insert funny messages. But (see below) *the signer cannot be the attacker*. It's nonsense. Either way, the paragraph needs clarification. 5. Section 3.4.5: INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria. I don't understand how this is an attack. If the signer said, I'm signing the first n bytes of the body of this message and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. Of course, that's why it's an informative implementation note. Though this appears again later in the document. You're saying that it's not worth pointing out pitfalls, and that we should stick to the facts of the protocol. No, that's not what I'm saying. If you want to put in an admonition, so be it. It's just not an attack. 10. Section 3.5, h=: INFORMATIVE EXPLANATION: The exclusion of the header field name and colon as well as the header field value for non-existent header fields allows detection of an attacker that inserts an actual header field with a null value. I cannot parse that sentence. I have no idea what it means. It's a horrible sentence, and needs rewording (or removal). But I know what it means. When you sign
Re: [ietf-dkim] Pete's review of 4871bis
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, June 29, 2011 9:20 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis I agree that 8.14 is poorly written (and it was even worse a while back). However, there most certainly IS an attack here, which is NOT the same as the related attack discussed in 8.15, and cannot be prevented by putting extra entries in the 'h=' tag. Unfortunately, many WG members have failed to understand the difference between the two. That's a mischaracterization of the objection. h=from:from:... was not meant to address the attack about which you are complaining. In my opinion, there needs to be some REQUIRED action in the verifier which will result in a PERMFAIL, and which would then catch all attacks of this nature. But the WG consensus has been against this. This was discussed ad nauseam. The consensus reached was that DKIM is the wrong place to enforce compliance of RFC5322. Rather, we stipulate that we expect those modules to do their jobs properly. Nobody has said either of the two variants of this attack are not valid concerns. The dispute is about what module in the handling of a message is responsible for detecting and dealing with it. Since the problem exists even with a message that is not DKIM-signed, I still fail to understand how this is specifically a DKIM problem. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
The first thing is that it's out of scope to address changes to things that were in RFC 4871, which was approved by the working group, the community, and the IESG in 2007, if it's simply a question of one or two people not liking those things so much -- even if one or two of those people now sit on the IESG. The working group has really made an effort to avoid casual changes, and I support that, as chair and document shepherd. RFC 4871 is full of gratuitous and often wrong advice on everything from APIs to MUA design to key management. 4871bis got rid of some of it, but there's still a lot left. If Pete can force us to strip out more of the gratuitous stuff and stick to telling people how to do reliably interoperable signing and verification, the actual standards part of the standard, he'll be doing everyone a favor in the long run. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On 6/29/2011 9:40 AM, John R. Levine wrote: RFC 4871 is full of gratuitous and often wrong advice on everything from APIs to MUA design to key management. 4871bis got rid of some of it, but there's still a lot left. If Pete can force us to strip out more of the gratuitous stuff and stick to telling people how to do reliably interoperable signing and verification, the actual standards part of the standard, he'll be doing everyone a favor in the long run. Well, perhaps you are right. After all, the group's ability to make decisions about changes, it's enthusiasm for such an effort and the community's demonstrated problems with the problematic text are all clear enough to easily justify our continuing to expend significant effort and to further delay publication of this document. Not. 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] Pete's review of 4871bis
On 6/29/11 11:20 AM, Charles Lindsey wrote: I agree that 8.14 is poorly written (and it was even worse a while back). However, there most certainly IS an attack here, which is NOT the same as the related attack discussed in 8.15, and cannot be prevented by putting extra entries in the 'h=' tag. Unfortunately, many WG members have failed to understand the difference between the two. Here is the attack, described in plain terms: A phisher obtains a throwaway domain and creates a public/private key pair for it. He then sends messages of the following form: To: some.sucker@anywhere.example From: eBaye...@ebay.co.uk Date: Tue, 17 May 2011 13:21:06 +0100 Subject: Some plausible Ebay subject Lots of other normal headers From: a.phisher@mythrowayawdomain.example DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example; h=from:to:subject:date; ... b=valid signature Body of message of typical Phish style. - A compliant DKIM verifier will report that as a validly signed message. The second From field is absolutely irrelevant in the example. The phisher could simply leave out the From field with their address in it and sign the ebay From field. And that's not an attack. The signer signed the message and the signature verifies. *DKIM* has done its job successfully and has not been attacked. DKIM communicates from the signer to the verifier. The signer *can't* attack itself. You *might* characterize this as an attack against 5322 (in that From addresses are not bound in any secure way to the actual author), but DKIM does not even attempt to address that attack, so it's not an attack against DKIM. You go on to say something that is an attack, but again you get the analysis wrong: The Ebay signature is irrelevant for the signing process (so even if Ebay has declared a Discardable ADSP policy it will not be invoked). Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack on ADSP. If ADSP sees the above message and doesn't discard it, then ADSP has done the wrong thing. If ADSP has a bug where it thinks it ought not discard the above message (with the appropriate policy), then that should be fixed. It should certainly be called out in the security considerations of ADSP. But it's NOT a security consideration for DKIM. Normal readers using current MUAs will see just the From: Ebay header and, believing that their ISP has done some magical cryptographic checks to prevent bogus Ebay messages from getting through, will be reassured. Again, the second From is not required for that to happen. If MUAs believe that some magical crypto thing happens to a message with d=badguy.example and From: ebay (with no other From's), then they get what they paid for. The present draft does make some woolly attempts to fix this problem. Section 3.8 says verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322] ... . But gives no guidance as to what reasonable means (and full RFC5322 compliance checking is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves it to the implelemtor to work out what he needs to do. As this conversation has developed (here and off line), I'm getting convinced that 3.8 is a red herring. DKIM deals perfectly well with the obsolete message format, including multiple From fields. I think the 3.8 admonition is overblown. In my opinion, there needs to be some REQUIRED action in the verifier which will result in a PERMFAIL, and which would then catch all attacks of this nature. But the WG consensus has been against this. If the WG is against it, it is correct. This is NOT a PERMFAIL condition for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a different document. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
On 6/29/2011 11:49 AM, Pete Resnick wrote: Now*that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack So? The original directive to produce a threats analaysis was for threats to recipients that DKIM might help remedy. Clearly, techniques later designed to circumvent or exploit DKIM weaknessare also relevant, but they aren't the only attacks that are relevant here. Also, I'm just guessing that that's what you mean by attack on DKIM. If I missed it, I apologize, but have you define what you mean by attack on DKIM? And why is it important to distinguish which category an attack falls into? 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] Pete's review of 4871bis
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, June 29, 2011 11:56 AM To: Pete Resnick Cc: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis If I missed it, I apologize, but have you define what you mean by attack on DKIM? And why is it important to distinguish which category an attack falls into? I'll offer this up: Something is an attack on DKIM if it involves input that can cause DKIM to report a pass when it should report a fail, or report d=example.com when it should've said d=example.org. Since the general output of DKIM is pass/fail and a domain name plus some other optional signature stuff, I fail to see how double-From type attacks are attacks on DKIM. Rather, I think these things we're discussing are attacks on MUAs (or on ADSP implementations) that fail to do RFC5322 enforcement or fail to understand what DKIM is telling them. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Pete's review of 4871bis
Hi John, At 09:40 29-06-2011, John R. Levine wrote: there's still a lot left. If Pete can force us to strip out more of the gratuitous stuff and stick to telling people how to do reliably interoperable signing and verification, the actual standards part of the standard, he'll be doing everyone a favor in the long run. Agreed. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Pete's review of 4871bis
Folks, I've been reviewing 4871bis for the IESG review on Thursday. I've got a huge number of comments. Some of them (e.g., the first two below) are quite trivial or simple issues that I expect you'd either have no issue with or that I'm happy to ignore; some of them are clearly not trivial at all. I have not entered a ballot position yet, and I haven't sorted through all of the comments to decide if any are worthy of entering a DISCUSS, but I suspect that some of them are. I therefore wanted to post this to the WG list so you all get an idea of what I'm thinking about. Tomorrow I'll spend some time cleaning these up and sorting them by category instead of by order of the document. I apologize for the lateness of this review; it's probably something I should have done a long time ago. Comments: 1. I find the use of the word INFORMATIVE throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose. 2. The ABNF 0* construct is not normally used. Why not just *? 3. Section 2.7: I don't understand what the word module means in this context. It sounds like some sort of specific implementation, not part of a protocol. I don't know what it means to deliver values to a module. 4. Section 3.4.4: INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude ASCII Art attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the simple body canonicalization algorithm should be used instead. This is not an attack, or at the very least it is not an attack on DKIM. You can play this same game with MIME encodings or other textual tricks. I don't see any justification for this note being in this document. 5. Section 3.4.5: INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria. I don't understand how this is an attack. If the signer said, I'm signing the first n bytes of the body of this message and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that seems outside the scope of this document. 6. Section 3.5: v= Version (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value 1. Note that verifiers must do a string comparison on this value; for example, 1 is not the same as 1.0. Why string comparison here? There's no case sensitivity to worry about. There's no character encoding to worry about. Why not instead say, Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple '1' is not the same as '1.0'? (Seem similar text in 3.6.1.) And why is the value not listed as plain-text? 7. Section 3.5: It would be nice to subsection each tag here. (e.g., v= could be 3.5.1, etc.) 8. Section 3.5, h=: It would be nice to add a sentence similar to the one in 5.4: The field MAY contain multiple instances of a header field name; this means that multiple occurrences of the header field are being signed by the signing algorithm. 9. Section 3.5, h=: INFORMATIVE EXPLANATION: By signing header fields that do not actually exist, a signer can allow a verifier to detect insertion of those header fields after signing. However, since a signer cannot possibly know what header fields might be created in the future, and that some MUAs might present header fields that are embedded inside a message (e.g., as a message/ rfc822 content type), the security of this solution is not total. a. I don't understand what MUAs presenting header fields that are embedded inside a message has to do with anything. b. I don't know what the words, the security of this solution is not total are supposed to mean. Don't you simply mean: However, since a signer cannot possibly know what header fields might be defined in the future, this mechanism can't be used to prevent the addition of any possible unknown header fields.? 10. Section 3.5, h=:
