Re: [ietf-dkim] layer violations, was detecting header mutations after signing
--On 14 October 2010 10:23:21 -0700 Michael Thomas m...@mtcc.com wrote: On 10/14/2010 10:15 AM, John R. Levine wrote: If you really think this is such a great big problem, maybe you should be banging the drums at MAAWG or other venues where the correct set of ears is potentially listening. I would rather not have to run a session at MAAWG entitled How to fix the security holes in DKIM, but I certainly could. Am I really the only person who wants to be able to whitelist mail signed with known good signatures, drop it into user inboxes and expect reasonable results with existing MUAs? I would hope so because this would be a really stupid thing to do. Without the next line of defense -- virus, malware, spam, phishing -- you'd be setting your users up for big problems. Just because it's DKIM signed from a good source doesn't mean it's not still evil. I think the emphasis in John's email was on expect reasonable results with existing MUAs If DKIM is any part of the evaluation process, then that's all thrown away if MUAs are showing the wrong email address as authenticated. That's why all of this hand wringing is silly. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
--On 14 October 2010 13:44:40 -0400 John R. Levine jo...@iecc.com wrote: That makes it invalid input to any module that requires input to comply with RFC5322, pure and simple. Well, OK, with the stipulation that no existing MUA I have ever seen is such a module. Nor MTA, either. Exim has a verify = header_syntax ACL option, which checks the syntax of headers that contain addresses, but it doesn't count headers, so it doesn't spot this problem. A bug report has been filed, so this conversation has helped there. I think if it becomes well-known that users of MUA 1 are easier to phish than users of MUA 2, a lot of people will gravitate to the safer implementation, don't you? I sure would. Aw, come on. How many millions of people still use Outlook Express on Windows XP? Switching MUAs is painful, people rarely do it. Too true. When I started working here in 1999, Siren Mail had just ceased development. We've only just (in the last few months) got Siren Mail out of the hands of the last user hanging on. And the motivation there was that Siren Mail didn't do authenticated SMTP! -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Ian Eiloart wrote: I think the emphasis in John's email was on expect reasonable results with existing MUAs If DKIM is any part of the evaluation process, then that's all thrown away if MUAs are showing the wrong email address as authenticated. MUAs are like children. They eat what we feed them and they can't exist without a backend. -- 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] layer violations, was detecting header mutations after signing
Murray S. Kucherawy wrote: Levine wrote: Aw, come on. How many millions of people still use Outlook Express on Windows XP? Switching MUAs is painful, people rarely do it. ...meaning MUA developers won't bother to do something about it once the attack is plainly visible and they're used as examples, because since users won't switch anyway, there's no motivation? The backend will address it first before the MUA needs too. Murray, most people are not haters and don't draw a line between good and bad because one isn't perfect and therefore begin to switch software like cheap wine. Since DKIM is betting its future on increase mail integrity and verified identities, it is a fundamental requirement that it checks key parts to make sure the integrity stays in tack. Passing the buck (or assuming others are better suited to deal with it) is not practical and bad PR for DKIM. In reality, all parts need to check for this, the MUAs, the backends and above all because of the extra special needs for trust - DKIM. The backends can't presume all the different MUAs used will address this, so it needs to address it. The DKIM components can't assume the backend or MUAs will address it, so it needs to address it itself. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Wed, 13 Oct 2010 18:13:43 +0100, Jim Fenton fen...@cisco.com wrote: My inclination is that the spec should say something like: - The verifier SHOULD consider the signature invalid if a signed header field occurs an inappropriate number of times in the message header according to section 3.6 of RFC 5322. - The verifier MAY consider the signature invalid if it detects other message syntax violations of RFC 5322. - (??) The verifier SHOULD consider the signature invalid if the List-Id header field is signed and occurs more than once in violation of RFC 2919. I think the first SHOULD needs to be a MUST (especially as it is a fairly simple test to implement). The MAY is fine. The second SHOULD is fine, except that it should be a blanket coverage of all other standards that define header fields limited to one occurrence. We can't expect implementers to keep up-to-date with EVERY such standard, but they should try to do as much as they can. If SHOULD is too strong for that sort of approach, then I would make it a MAY with an encouragement do you as much as they can. Obvious candidates are the List-* headers and RFC204[56]. The last provision worries me a bit because it opens the door to other specifications that define header fields. On the other hand, I can picture an attack involving insertion of a bogus List-Id header field in order to influence the handling of the message. See above. -- 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-02 - Section 8.14 comments
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton fen...@cisco.com wrote: Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. OK, we're gradually moving towards an acceptable text, but we're not there yet. ... Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 ... +1 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? So I think there is a wide range of possible attacks involving duplicated headers, and the text needs to be general enough to cover them. According to [RFC5322] ... signed header fields occurs. Multiple occurrences ... as discussed in Section 3.5. Suggested update to paragraph 2 of section 5.3: Similarly, a message not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See the Section 8 of [RFC4409] for examples of changes that are commonly made. Such corrections may break DKIM signatures or have other undesirable effects. Therefore, a DKIM signer SHOULD confirm that a message is compliant with those specifications prior to processing. /t +1 Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. I have a problem with meticulously validate. That is so hard to do that most implepemters will take advantage of that SHOULD and omit the tests. Much better to specify a less meticulous validation (header counting for example) and then elevate that SHOULD to a MUST. Here is an alternative text that I published on Oct 6th (and on which nobody commented). It is intended to go in section 6.1.1, presumably after the paragraph beginning If the h= tag ...: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if more than 1 occurrence of that header field is present in the message, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (multiple occurrences of XXX header field). Moreover, it SHOULD so treat any header field defined in any other standards track document to have a maximum occurrence of 1. If you think that is a bit too vicious, here is a slightly more permnissive version: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if the number of occurrences of that header field present in the message exceeds its number of occurrences in the h= tag, ... -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 15:17:15 +0100, John R. Levine jo...@iecc.com wrote: We seem to be talking past each other here. I don't see anyone proposing a deep dive into 5322 validation. But 4871 already says you MUST sign the From: header. Why is that OK, but saying you MUST NOT sign or validate something with two From: headers is not? We're not suggesting anything that would invalidate existing bits on the wire, after all. +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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 17:45:39 +0100, John R. Levine jo...@iecc.com wrote: Well, yeah. That's why I don't understand why people are so opposed to a SHOULD saying they should. Or even a MUST saying they must. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:01:25 +0100, Michael Thomas m...@mtcc.com wrote: Because the audience who ought to be dealing with the larger problem has little to nothing to do with the audience that would have to deal with that MUST/SHOULD. It's a useless requirement to put on DKIM. So which two audiences do you have in mind? The primary audience is the people who write verifiers for boundaries. The end users are hardly an audience at all since they are not listening directly to us, and they are likely using software that is 10 years old, and are unlikely to change. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas m...@mtcc.com wrote: I would hope so because this would be a really stupid thing to do. Without the next line of defense -- virus, malware, spam, phishing -- you'd be setting your users up for big problems. Just because it's DKIM signed from a good source doesn't mean it's not still evil. Have you ever seen an evil message from Ebay? And yet the current protocol will allow an evil mail _apparently_ from Ebay to appear, with no means for the recipient to detect the difference. And as regards using current malware detection software, can you please explain to us how that is supposed to catch an eveil mail signed by a brand-new throwaway domain that has not yet had time to acquire any reputation, good or bad? That's why all of this hand wringing is silly. We are not hand wringing. We are pointing out a protocol that, when applied in the current (and likely future) Real World, fails to deliver what it was intended to deliver. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:30:38 +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 John R. Levine Sent: Thursday, October 14, 2010 10:15 AM To: DKIM List Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing Am I really the only person who wants to be able to whitelist mail signed with known good signatures, drop it into user inboxes and expect reasonable results with existing MUAs? Not only do I want that, I did that. But the DKIM/ADSP module of that system is purely DKIM/ADSP. The module that sits between the MTA and the DKIM/ADSP module does the header count enforcement we're talking about, knowing there's the potential for invalid mush in there. Which module does which bit of the counting/DKIM/ADSP is a minor implemention detail. Any DKIM verifier MUST be associated with a counting mechanism, and whether this is done within itself or by some other module within the overall MTA is neither here nor there. And ADSP also needs to make it clear which From header it needs to look at; and until that is fixed we MUST assume that it will look at whichever From header gives the worst outcome. -- 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-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 9:06 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton fen...@cisco.com wrote: Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. OK, we're gradually moving towards an acceptable text, but we're not there yet. ... Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 ... +1 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? The particular danger that comes to my mind would be where the signing domain uses l= (yes, I know there is a warning against doing this why don't we just deprecate l=?). If evil ne'er-do-well can get a short, somewhat generic signed email from a low level person at an organization then they can potentially leverage this with the multiple headers to generate a spear phishing attack. I have not trod to far down this path to construct a proof of concept but a google for DKIM + l= yielded examples (Assuming you are willing to wade through a bunch of results) of domains using l=, most likely out of ignorance (a fertile breeding ground for abuse). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely ves...@tana.it wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. That only works when the signature is created by the Good Guys. When the Bad Guys create signatures (using a throwaway domain), they will conveniently forget to do h=from:from. The only way that DKIM can consistently account for this exploit is by amending section 5.5 Recommended Signature Content, and spell what fields MUST/SHOULD be duplicated in the h= tag. No, the only way is to amend DKIM so that the verifiers MUST/SHOULD take the right action. -- 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] Last call comment: Changing the g= definition
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER d...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Thu, 14 Oct 2010 17:30:42 +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: Thursday, October 14, 2010 7:32 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing But if there is no valid DKIM signature, the verifier will proceed to do ADSP checks, and will reject the message if it sees that ebay.com is 'discardable'. ADSP is a completely separate discussion. We're talking about advancing DKIM here, not both of them. ADSP is largely the cause of our troubles. But since we are not going to change it (just yet), we have to make DKIM work as well as it can with the current ADSP. And the Bad Guys are perfectly well aware of what ADSP does and how it is deployed by the Good Guys. And so if they find they can circumvent ADSP by signing messages with their own throwaway domains, then they will do so. And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. -- 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-02 - Section 8.14 comments
In article 201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? 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 14/Oct/10 20:09, Mark Delany wrote: On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. Which strikes me as an ugly hack. Given that most headers should only occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Yes, it does. The only question is to devise normative statements correctly, e.g. MUST duplicate From, SHOULD duplicate the rest. This is _not_ a kludge. It is how DKIM signing works (Section 5.4). Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb headers nowadays, so that is about 3% of it.) Introducing an abbreviation --e.g. an h2 tag-- is considerably clearer from an algorithm developer's POV. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Folks, The pattern is completely consistent, so I will take this as agreement to remove both. Anyone objecting very strongly needs to speak up. 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] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 17:13, John Levine wrote: In article201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? For me, it works as advertised: I can verify my own messages when they come back from a list that just adds footers. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/15/2010 06:51 AM, Charles Lindsey wrote: On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomasm...@mtcc.com wrote: I would hope so because this would be a really stupid thing to do. Without the next line of defense -- virus, malware, spam, phishing -- you'd be setting your users up for big problems. Just because it's DKIM signed from a good source doesn't mean it's not still evil. Have you ever seen an evil message from Ebay? s/Ebay/Yahoo!, etc, yes. And yet the current protocol will allow an evil mail _apparently_ from Ebay to appear, with no means for the recipient to detect the difference. They're not apparently from them. They *are* from them. DKIM is not any indication of whether the content is evil or not, per se. It just says who to complain to if it is evil. And as regards using current malware detection software, can you please explain to us how that is supposed to catch an eveil mail signed by a brand-new throwaway domain that has not yet had time to acquire any reputation, good or bad? Irrelevant for the current discussion. Mike That's why all of this hand wringing is silly. We are not hand wringing. We are pointing out a protocol that, when applied in the current (and likely future) Real World, fails to deliver what it was intended to deliver. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 6:58 AM To: DKIM Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing Which module does which bit of the counting/DKIM/ADSP is a minor implemention detail. Any DKIM verifier MUST be associated with a counting mechanism, and whether this is done within itself or by some other module within the overall MTA is neither here nor there. This continues to conflate specification with implementation. You're talking about the latter, I'm talking about the former. And ADSP also needs to make it clear which From header it needs to look at; and until that is fixed we MUST assume that it will look at whichever From header gives the worst outcome. The current effort has everything to do with moving DKIM to draft standard, and nothing at all to do with handling ADSP issues. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/15/10 6:06 AM, Charles Lindsey wrote: On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fentonfen...@cisco.com wrote: 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? An attacker could compose a message from some other domain with a good reputation, and add a From header indicating it's really authored by someone at a different domain (say by ebay). Even if ebay has an ADSP record, it's possible that the invisible (originally) From address would be used to in the author signature check, which would pass. I'm also concerned about other header fields, like Subject, where a one-line spam could be substituted as the visible subject line for a signed message. So I think there is a wide range of possible attacks involving duplicated headers, and the text needs to be general enough to cover them. Agree. Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. I have a problem with meticulously validate. That is so hard to do that most implepemters will take advantage of that SHOULD and omit the tests. Much better to specify a less meticulous validation (header counting for example) and then elevate that SHOULD to a MUST. We can drop the meticulously part. It was put there for consistency with the validation of the signature header field (current section 6.1.1) but I agree, probably isn't a practical requirement. Here is an alternative text that I published on Oct 6th (and on which nobody commented). It is intended to go in section 6.1.1, presumably after the paragraph beginning If the h= tag ...: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if more than 1 occurrence of that header field is present in the message, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (multiple occurrences of XXX header field). Moreover, it SHOULD so treat any header field defined in any other standards track document to have a maximum occurrence of 1. If you think that is a bit too vicious, here is a slightly more permnissive version: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if the number of occurrences of that header field present in the message exceeds its number of occurrences in the h= tag, ... The header field limitations are more complex than that (see Resent-Sender). I prefer to more simply refer to the appropriate section of RFC 5322 and say that it must be adhered to. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, October 15, 2010 2:13 AM To: Barry Leiba Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? It's a specific example of a more general statement, and the general statement is still there in what Jim said. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/15/10 2:12 AM, Alessandro Vesely wrote: On 14/Oct/10 20:40, Barry Leiba wrote: 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -1 If we go for changing the protocol in order to avoid the exploit, we should explicitly enumerate the header fields whose duplication verifiers MUST check. SHOULD meticulously validate + MUST return PERMFAIL make for a fuzzy protocol. I think this is clear in Jim's text, and not contradictory or fuzzy at all. They SHOULD check. If they check and the message violates the checks, they MUST return a PERMFAIL. Where's the contradiction or confusion? Fuzziness stems from the fact that a signature on a given message may either verify or not depending on how meticulously the verifier interprets that SHOULD. The MUST immediately following it is deceptive because it conveys the false impression that a signature is REQUIRED to fail in case a particular header field is added after signing. Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? I wanted it to be clear that it's the verifier's job to detect the duplication, not the signer's job to work around the problem. Recall that SHOULD means, roughly Do it unless you have a valid reason not to, and have considered the implications. Besides, as Mark Delany said yesterday, having to do h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id strikes me as an ugly hack. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. It does. A message that has two From lines, for example, is in violation of RFC 5322. It makes no difference whether it's signed or not. RFC 5322 (and the other specs) doesn't know about the signature and doesn't care, and anything that checks compliance with it doesn't care either. MUAs often disallow writing a From with multiple mailboxes, thus a sender may happen to end up with two From fields after hacking in an attempt to recognize authorship to a second mailbox. Are you saying that there are MUAs that disallow a From: with multiple addresses, but support the addition of multiple From: header fields? If so, I hope it's not a popular MUA that's doing this. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 08:28 AM, Dave CROCKER wrote: On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Folks, The pattern is completely consistent, so I will take this as agreement to remove both. Anyone objecting very strongly needs to speak up. I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with SPF TXT records
Folks, I really think we should use the opportunity to add a note about DKIM adopters having potential DNS setup issues due to wildcard SPF records. When section 3.6.2.1, SPF was probably still growing and not wide spread with Web-Based DNS managements from ISPs. Today, a special Add SPF record option is available. At least at one ISP/Domain Registrar (one of the original biggest), it only allows a wildcard TXT record to cover the non-prefix SPF query. This conflicts with added DKIM and ADSP dns records. The section already has an INFORMATIVE OPERATIONAL NOTE advising not to use wildcards for DKIM public keys records. What I am suggesting is another short INFORMATIVE OPERATIONAL NOTE, not about a tutorial on DNS management, but maybe just saying: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records for SPF records may conflict with DKIM TXT sub-domain TXT records. DNS management software should not require only Wildcard SPF entries and should allow for non-prefix SPF TXT enries. The readers of this document will include web developers for DNS zone file management when considering DKIM record support and having this new informative note will guide them in not being conflictive with DKIM TXT record lookups. The only reason I like for people to consider this is because I got an email today that Network Solutions isn't going to address this issue for the customer. So like Murray likes to admonish those for lack of compliancy and to encourage to fix problems, having the helpful information operational node will help admonish DNS management software developers to maybe correct their current implementations. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 6:52 AM To: DKIM Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing That's why all of this hand wringing is silly. We are not hand wringing. We are pointing out a protocol that, when applied in the current (and likely future) Real World, fails to deliver what it was intended to deliver. This to me says you still believe DKIM's ultimate payload is something other than a validated identifier, in this case a domain name. We're thus not on the same page. If instead we do agree that that's its sole intended purpose (and consensus on the errata RFC was achieved, thus confirming this), then you also have to agree that DKIM already does that. The MUAs simply fail to make use of it, and that's the real problem. DKIM does not purport to guarantee delivery of something that an MUA is incapable of misrepresenting. The proposed changes don't improve this. And since we're all insisting MUA developer and user inertia is here to stay, then even all the fixes we're talking about aren't going to make the enforcement of header field counts visible to end users; the sum and substance of the impact will be that the Authentication-Results header field (or other annotation) will change from fail to pass, but this is rarely rendered to end users, and so the problem remains. RFC5451 says an Authentication-Results field shouldn't include in its authentication summary any data that wasn't authenticated. Blocking presentation of unauthenticated data, or highlighting it as dubious, or outright obstruction of its delivery, are the right ways to deal with this. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 15, 2010, at 9:50 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: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. +1. Any bug fixes for ADSP need to be done at the ADSP level. If there's a bug that needs fixing at the DKIM level then if should be something that clearly needs fixing based on DKIM usage. (And I think that the very narrow case of messages that violate 5322 through multiple headers *may* be such, but any justification of that relying on ADSP isn't helpful). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Friday, October 15, 2010 10:04 AM To: DKIM Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing And since we're all insisting MUA developer and user inertia is here to stay, then even all the fixes we're talking about aren't going to make the enforcement of header field counts visible to end users; the sum and substance of the impact will be that the Authentication-Results header field (or other annotation) will change from fail to pass, but this is rarely rendered to end users, and so the problem remains. That should be pass to fail, of course. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Steve, I believe its about protocol consistency. While the main focus is DKIM progress, its issues and resolutions are related to ADSP as well as its a WG product as well. For example, ADSP implementations now know that they need to make there is only one 5322.From as well. Like most software, when it has a header = GetMailHeader(From:) it is not expected to return a list of headers, but a single entry and that generally done by finding the first one. In short, we have marked this on the WG to-do list for ADSP updates if any, and implementations now know what they need to add to their ADSP support. Its all about synergism. We can't just completely ignore it and then miss something that needs to be done later. -- HLS Steve Atkins wrote: On Oct 15, 2010, at 9:50 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: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. +1. Any bug fixes for ADSP need to be done at the ADSP level. If there's a bug that needs fixing at the DKIM level then if should be something that clearly needs fixing based on DKIM usage. (And I think that the very narrow case of messages that violate 5322 through multiple headers *may* be such, but any justification of that relying on ADSP isn't helpful). Cheers, Steve ___ 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] Last call comment: Changing the g= definition
I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Therefore, the consensus that goes into the document will reflect what the chairs see. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Friday, October 15, 2010 10:17 AM To: IETF DKIM WG Cc: Barry Leiba Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. I was threatened with legal action on the basis of tortious interference if I continued to disagree with one participant's technical arguments or professional conduct on this list. I have thus elected not to engage that person any further in any discourse whatsoever on the list absent a withdrawal of that threat and some kind of guarantee of future civility. I have serious doubts the IESG would find fault in that choice on appeal. The IETF has dealt severely with other participants that have taken that attitude in the past. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On Fri, Oct 15, 2010 at 1:17 PM, Hector Santos hsan...@isdg.net wrote: In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. You're certainly welcome to file an appeal, if you think there's been a procedural problem. The first step, of course, is to bring the issue to the attention of the chairs (which you have), and the next is to discuss it with the responsible AD (Sean). I'm actually pretty certain that neither Dave nor Murray is deleting your (or anyone's) messages outright, though I can't guarantee that they're reading everything you have (or anyone has) to say. This is meant as a general statement to all: you can increase the chances that people will read your posts if you post clearly, concisely, and calmly (the three Cs?), and avoid invective and excess. In any case, as I said in reply to Mike, the chairs are paying attention to the whole discussion, and we will be evaluating consensus fairly. Note that that still means that even if one or two people disagree with something, rough consensus might go against them. It also means that if other participants agree with the objections and say so, the consensus might go that way as well. Barry, as fair chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:32 AM, Barry Leiba wrote: I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Barry, would that it worked that way. I have on many occasions supplied text, alternative wording, etc, only be completely ignored because I'm in Dave's killfile. Editors with killfiles should not be editors. Period. It completely breaks down the working group process. It's particularly galling since I'm one of the AUTHORS and FIRST IMPLEMENTER of the spec under revision. Remove Dave immediately. Mike, I prefer this discussion remain public Therefore, the consensus that goes into the document will reflect what the chairs see. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
I was threatened with legal action [...] I understand why you posted this, but, please, let's not continue this sort of discussion on the list. Everyone, we're here to find consensus and develop specifications. Let's no one attack anyone else; let's work on cooperating. As a conference button I once had says: Calm down: it's only ones and zeroes. Barry, as stern chair (who could use some port about now) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 2 Day Collection Stats
This is a small 2 days collection break down of the signed mail coming in: Thanks. -- 25.9% : dkim_body_hash_mismatch I was going to ask... I should probably add a recording which of these has List-IDs, but I think the high body hash failures are most list systems. ...but you answered. interesting to see such a high selector failure. I think the 2.8% invalid selector has to do with mix ups with SPF records. Yes, interesting, indeed. Related to one of the current discussions, can you check the presence of g=x in the key records, where x is neither empty nor * ? Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/10 7:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Given the lack of (useful) deployment of g=, and the consensus to move away from using actual mailbox addresses in the local-part of i= (which means that g= is matching with, potentially, an opaque value), I support this. However, we still need to caution DKIM signers deploying DKIM that they need to make sure that their selector records don't contain empty g= values, because there will be verifiers that check g= for a very long time. As I said before, my preference is to put that advice directly in 4871bis, in order to make sure that it is seen. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
For the record, what you were told was that if your childish action of filtering me extended to telling others to filter me, that would be grounds for tort. Apparently, I am not the only one who feels the consensus process is being skewed by key editors filtering of WG Participants that don't always agree with with the direction or changes to the WG documents. While you have all the right to filter your WG mail, that doesn't sound like good IETF engineering with the requirement of being open minded. You being a key editor of the nearly all the documents know requires you to BACK OFF and take in all the input and try to block them in their inputs. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Friday, October 15, 2010 10:17 AM To: IETF DKIM WG Cc: Barry Leiba Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. I was threatened with legal action on the basis of tortious interference if I continued to disagree with one participant's technical arguments or professional conduct on this list. I have thus elected not to engage that person any further in any discourse whatsoever on the list absent a withdrawal of that threat and some kind of guarantee of future civility. I have serious doubts the IESG would find fault in that choice on appeal. The IETF has dealt severely with other participants that have taken that attitude in the past. ___ 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] 2 Day Collection Stats
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Friday, October 15, 2010 10:48 AM To: Hector Santos Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 2 Day Collection Stats -- 25.9% : dkim_body_hash_mismatch I was going to ask... I should probably add a recording which of these has List-IDs, but I think the high body hash failures are most list systems. ...but you answered. We do have that recorded. Of 10,561 signatures for which the body hash failed, 8,219 (77.8%) appeared to be list traffic (i.e. had a List-* header field or a Precedence: list field). Breaking that down further: Of the 8,219, 6,614 (80.4%) were author domain signatures, so the rest were presumably list signatures (or something else). 57 of them failed even in the presence of an l= tag. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton Sent: Friday, October 15, 2010 10:25 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition Given the lack of (useful) deployment of g=, and the consensus to move away from using actual mailbox addresses in the local-part of i= (which means that g= is matching with, potentially, an opaque value), I support this. However, we still need to caution DKIM signers deploying DKIM that they need to make sure that their selector records don't contain empty g= values, because there will be verifiers that check g= for a very long time. As I said before, my preference is to put that advice directly in 4871bis, in order to make sure that it is seen. I think we'll need an IANA action to do the following: - add a column to the key tag registry indicating current status (and declare valid status values) - set a status for everything currently in the registry, including changing g= to obsolete And we need an informative appendix detailing that g= was removed for lack of deployment use, plus the cautionary point you just made. Does that sound right? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 18:59, Jim Fenton wrote: On 10/15/10 2:12 AM, Alessandro Vesely wrote: Fuzziness stems from the fact that a signature on a given message may either verify or not depending on how meticulously the verifier interprets that SHOULD. The MUST immediately following it is deceptive because it conveys the false impression that a signature is REQUIRED to fail in case a particular header field is added after signing. Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? I wanted it to be clear that it's the verifier's job to detect the duplication, not the signer's job to work around the problem. Recall that SHOULD means, roughly Do it unless you have a valid reason not to, and have considered the implications. The implications are that instead of having a signature that is either valid or not we'll have signatures that verify according to a variable percentage of existing verifiers, as it is for virus detection. Why not mandate to fail verification if the signed body contains a virus? To clarify, I'm not against changing DKIM. However, if we do, we better integrate the change in the original design. First of all, it should be in section 5.4. Second, it has to be an explicit list of header fields, rather than generic references to RFC 5322, RFC 2919, etcetera. Third, the spec should state that any repetition of such fields in the h tag, e.g. h=from:to:from:to, has to be regarded as a backward compatible guard, and new implementations must discard duplicated names retaining their first occurrence only. Then, it can derive the implication that signers cannot produce a valid signature of a message whose header actually contains multiple instances of any listed field... Lots of work and some semantic change... Besides, as Mark Delany said yesterday, having to do h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id strikes me as an ugly hack. But then the whole DKIM-Signature is an ugly hack :-) MUAs often disallow writing a From with multiple mailboxes, thus a sender may happen to end up with two From fields after hacking in an attempt to recognize authorship to a second mailbox. Are you saying that there are MUAs that disallow a From: with multiple addresses, but support the addition of multiple From: header fields? If so, I hope it's not a popular MUA that's doing this. One can always find ways or extensions to add /any/ header field more easily than for modifying existing ones. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
support On Oct 15, 2010, at 1:58 PM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair ___ 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] 2 Day Collection Stats
Breaking that down further: Of the 8,219, 6,614 (80.4%) were author domain signatures, so the rest were presumably list signatures (or something else). 57 of them failed even in the presence of an l= tag. More work for Murray. Distribution of the l= values? Particularly l=0 Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. Folks, (First rule of politics and legal trials: if you can't win on the substance, try to win on the process.) Since this is a formal forum and we're in the middle of a formal act (making a decision) and the mailing list is a formal record, I'm feeling compelled to correct two factual errors, in spite of the potential for this taking us down the rabbit hole: 1. I don't killfile. 2. I reviewed all mailing list postings in the thread that followed my query. d/ ps. However I happen to agree with Barry's note about requirements. But an inaccurate formal record warranted correcting. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 15/10/10 18:32, Barry Leiba wrote: I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Right. (Though having so much mail is almost as effective as a killfile;-) In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Therefore, the consensus that goes into the document will reflect what the chairs see. Indeed, S. Barry, as chair ___ 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] I-D Action:draft-ietf-dkim-mailinglists-04.txt
-Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Friday, October 15, 2010 11:15 AM To: i-d-annou...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: I-D Action:draft-ietf-dkim-mailinglists-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-04.txt Pages : 29 Date: 2010-10-15 [...] This version takes into account the latest feedback. As there hasn't been much since the 4871bis debates took over, it seemed like a good point to post a revision. Chiefly the feedback was from Charles pointing out that the verifier/receiver filtering action was not being represented consistently. The rest was largely typos. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 2 Day Collection Stats
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Friday, October 15, 2010 11:15 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 2 Day Collection Stats 57 of them failed even in the presence of an l= tag. More work for Murray. Distribution of the l= values? Particularly l=0 Total signatures to date: 333764 Signatures with no l=: 319774 (95.8%) Signatures with l=0: 1120 (0.3%) Signatures with other l= values: 12870 (3.9%) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 11:19 AM, Dave CROCKER wrote: On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. Folks, (First rule of politics and legal trials: if you can't win on the substance, try to win on the process.) Chairs: I object to the ad hominem attack. In this case, it is a monkey trail, because Dave simply ignores (by kill file, or by whatever other means he chooses to employ) any suggestions of people he has assigned to his bozo filter, a filter purely of his own making, and not driving by any sort of working group consensus. This is why he is an extremely poor choice for being named editor, a choice that I objected to at the time for this very reason. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 10:58 AM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? I'm not sure whether wildcard records is relevant to the spec - that's more of a development, deployment and operations issue, I think. As a verifier implementor I'm not that interested in why someone is publishing bogus key records as I am in what I should do about them (fail if any are invalid, fail if there are multiple, check all of them and pass if any are valid...) - what's an appropriate response from the verifier in the case that the TXT records returned are unexpected. So the existing wording is harmless, and I'd support adding it, but something a little bit more prescriptive might be better. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:45 AM, Stephen Farrell wrote: In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Stephen -- the issue here is the procedural one that Dave ignores *any* input *at all* from people he filters. It doesn't matter whether it's a typo -- ignored. This has been true of every document in this working group that he has edited. In the case of 4871-bis that means that I can have *no* input whatsoever, even though I'm one of the authors of 4871 and have made substantial contribution to the community with stats, running code, and general insight about what running DKIM was like in a large enterprise setting. I'm fine with Dave not liking me as an individual and choosing to ignore me, but not with an editor's hat on. If he can't put that aside as an editor, he should recuse himself and step down. Mike, nothing I say here makes any difference because of who gates the changes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 2 Day Collection Stats
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Friday, October 15, 2010 11:41 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 2 Day Collection Stats 57 of them failed even in the presence of an l= tag. More work for Murray. Distribution of the l= values? Particularly l=0 Total signatures to date: 333764 Signatures with no l=: 319774 (95.8%) Signatures with l=0: 1120 (0.3%) Signatures with other l= values: 12870 (3.9%) And, anticipating the next question(s): Signatures with other l= values that were in turn larger than the message received: 10389 Subset of those that still passed: 9870 (95%) Subset of those that still passed and looked like list traffic: 5504 (53%) Based on that it looks like l= is pretty effective, but not very widely used. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Barry, as chair I'm neutral on the subject of covering this topic, but if we are going to cover it, this or similar text is good. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/15/2010 2:46 PM, Steve Atkins wrote: I'm not sure whether wildcard records is relevant to the spec - that's more of a development, deployment and operations issue, I think. The degree to which a processing environment is expected to be pure versus potentially noisy might well come into play during the specification phase. For example, it might be why a distinguishing label gets added. In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. 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] ISSUE: 3.6.2.1 - Working with other TXT records
At 08:25 14-10-10, Hector Santos wrote: I don't think I am suggesting to get into the bad DNS managements tools. But the section is short on what are possible error issues. One of them is making sure other TXT records don't conflict. I think that can be a general, generic statement that does not get into poor DNS management tools implementation. There are possible error issues which you won't find in the RFCs for DKIM. The wildcard in DNS is a known issue. You can catch it by looking for the DKIM1 tag in the DNS reply. If you are going to get into fixing the DNS side in the specification, you are opening the way to a new set of problems that are better addressed by a working group which is tasked to tackle DNS issues. You may, for example, encounter DNS failures because the primary is not in sync with the secondaries; or the backslash in the _domainkey DNS record; or assumptions that DNS queries should always be over UDP. At 09:22 14-10-10, Murray S. Kucherawy wrote: Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? That document is not a better reference as it is not about how DNS works. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-04.txt Pages : 29 Date: 2010-10-15 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. As the industry has now gained some deployment experience, the goal for this document is to explore the use of DKIM for scenarios that include intermediaries, such as Mailing List Managers (MLMs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-04.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 2 Day Collection Stats
Murray S. Kucherawy wrote: And, anticipating the next question(s): Signatures with other l= values that were in turn larger than the message received: 10389 Subset of those that still passed: 9870 (95%) Subset of those that still passed and looked like list traffic: 5504 (53%) Based on that it looks like l= is pretty effective, but not very widely used. I did a short testing on this (but turned if off for now) where for one domain, I prepared the signing to: - use l= - excluded Subject in h= and the list mail survived with the original signature and the new resign signature. What it basically told me that we (my implementation) might have to add feature for a Target signing rule: if target is for a list then use - use l= - excluded Subject in h= otherwise - don't use l= - subject is in the h= But right now, list mail resigning strips the original. -- 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: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:22 PM, Murray S. Kucherawy wrote: Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? As much as I like to tout email-arch, the citation here needs to be specifically about the DNS and, for example, not about the DNS for mail. The fact that we hadn't even thought to include such basic citations in the original work on the draft provides good insight about the reader we are adding these for... 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] ISSUE: 3.6.2.1 - Working with other TXT records
The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. THat is the least of its problems. DKIM records go into a protected subbrance, given the underscore name. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. we've just fixed that during the current edits. 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] ISSUE: 3.6.2.1 - Working with other TXT records
On Fri, Oct 15, 2010 at 1:58 PM, Barry Leiba barryle...@computer.org wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? Does ADSP need to be mentioned? Otherwise +1. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jeff Macdonald Sent: Friday, October 15, 2010 12:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records Does ADSP need to be mentioned? Otherwise +1. I don't think so. ADSP's built on top of DKIM, not the other way around. We could say the same thing in ADSP though if there's ever an ADSPbis (deity-of-your-choice help us...). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... On Oct 15, 2010, at 11:53 AM, Dave CROCKER wrote: On 10/15/2010 11:40 AM, Mark Delany wrote: Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: This would mean that it is /never/ ok to add a listed header field after signing. Adding would /always/ break the signature. That's a very powerful semantic change. I've no idea that it's completely safe. It seems like it ought to be, but I worry about corner cases. d/ ps. I would expect such a semantic change to require re-cycling the spec at Proposed. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. SM, You can tell me if I am wrong here cause I am trying to make sure I understand the IETF angle to this but I also a product developer and have to look at the customer support angles as well. 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. This would be an implementation bug in our software if indeed that is what happening with invalid selector DKIM fails. 2) If #1 isn't part of the specs.. then I think there should be some note regarding working with other TXT records and to provide guidelines to DNS management software people to not enforce a wildcat only TXT record management solution for their customers. The note should not add a requirement for verifiers though (if this is going to an IETF RFC issue). However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. Note: For SPF, verifiers are already expecting and looking for the v=spfxxx strings in merged TXT records responses. This is required to support SPF and SENDERID. I see this as one of those things of an aged document drafted 4-5 years ago at the time where SPF was viewed as a competitive solution to DKIM and mentioning SPF or giving it credit for existing was probably not on editors mind. But today, SPF is real. Domain Hosting sites have tools to support it for the small to mid size market that are using their domain hosting name servers. DKIM should realize its wide presence from a DNS public key standpoint, not in a How to but to provide insight about the possible conflictive issues and I think its really just about those pesky wildcard DNS feature as Crocker put it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 15, 2010, at 1:51 PM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. How can the system be gamed by breaking a signature in a way that it can't be by removing the signature? A concrete example might make it clearer what the concern is. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. Nobody is saying it should be ignored, I don't think. Rather the bit of code that should be objecting to it is not the DKIM verifier. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Friday, October 15, 2010 1:52 PM To: Bill Oxley @ Cox; dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I think the problem is it's hard to tell using an algorithm. A human can perhaps look at a modification and qualify it as an operational side-effect or something deliberate intending to deceive, but it's pretty hard to codify that kind of logic, especially without some foreknowledge about what downstream agents are going to do with the message (which would make such an algorithm heinously big). I recognize what Murray and Dave have said on this point but it grates. I think it's an unfortunate reality as well; absent a way to tell the difference, it seems the best option is to act like there isn't any difference. Interestingly, I think the same logic applies to domain reputation: It's easy to shed a bad reputation by changing domains, so in the end I expect a bad reputation will be the same as no reputation. -MSK ___ 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/15/10 1:51 PM, MH Michael Hammer (5304) wrote: On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. Agreed. Having the specification suggest multiple From header fields should not report a valid signature is not enough. It will be years before software will reliably deal with the resulting exploits. The best method to handle DKIM related exploits at the MTA would be to recommend message refusal. It is hard to understand the reluctance in having a SHOULD refuse. Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. The h=from:from is also not an effective solution, as this only deals with one mode of exploitation! There are two. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] removing the g= definition?
On 10/14/10 6:54 AM, John R. Levine wrote: Another potential option is to remove g= entirely: I'd like to encourage our considering this strongly, for two reasons: I agree, g= seems to me to be a vestige of the confusion between i= and d= identity. If we do, it's probably a good idea to put in Tony's WARNING for people upgrading from DK. +1 -Doug ___ 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/15/10 10:58 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Friday, October 15, 2010 1:52 PM To: Bill Oxley @ Cox; dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. The problem is: when is a broken signature an intentionally broken signature and how do we detect that at the verifier side? For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. -1. At the end of the day, giving a negative score to an invalidated signature will/may affect the reputation of the owner of the domainname or better said: it will influence the way the assessor will interpret the authentication results provided by the verifier. Apart from the problem of how to determine the 'nature of the invalidation'. I think the problem is it's hard to tell using an algorithm. A human can perhaps look at a modification and qualify it as an operational side-effect or something deliberate intending to deceive, but it's pretty hard to codify that kind of logic, especially without some foreknowledge about what downstream agents are going to do with the message (which would make such an algorithm heinously big). I recognize what Murray and Dave have said on this point but it grates. I think it's an unfortunate reality as well; absent a way to tell the difference, it seems the best option is to act like there isn't any difference. Interestingly, I think the same logic applies to domain reputation: It's easy to shed a bad reputation by changing domains, so in the end I expect a bad reputation will be the same as no reputation. +1 Like DNSBLs and IPv6: at some point it will be more effective to whitelist known 'good' IP addresses than to blacklist the ever changing IP addresses of the bad guys. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/15/10 10:58 AM, Barry Leiba wrote: On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. +1. However, I'd be fine with adding some informative guidance to DKIM implementers reflecting current experience, something like: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. Thank you Murray. Something small and sweet will be useful, and your text is good enough. Good; we have a start. Will others please indicate support (or not) for adding this or similar text ? +1 -Doug ___ 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/15/10 8:40 AM, Mark Delany wrote: h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Yes, it does. The only question is to devise normative statements correctly, e.g. MUST duplicate From, SHOULD duplicate the rest. This is _not_ a kludge. It is how DKIM signing works (Section 5.4). Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb headers nowadays, so that is about 3% of it.) Introducing an abbreviation --e.g. an h2 tag-- is considerably clearer from an algorithm developer's POV. Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: Old verifiers still work as well as they do today, new verifiers work better and virtually all existing signers still work (excepting those that sign a subset of legitimately repeating headers - which must be rare). In either cases, the implementation changes are about the same, but the spec is simpler. Agreed. But use of the h=from:from prevents one mode of exploitation, because this requirement until now had not been made explicit. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304): -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I'm sure this was discussed before, but perhaps a refresher helps. How would the DKIM validator know the difference between: A: The message had a valid signature, but it was broken after signing. B: The message is a forgery with a bogus signature. If the DKIM validator cannot make that distinction, then the bad guys will do B and the validator will treat it as A. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 15/10/10 19:48, Michael Thomas wrote: On 10/15/2010 10:45 AM, Stephen Farrell wrote: In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Stephen -- the issue here is the procedural one that Dave ignores *any* input *at all* from people he filters. It doesn't matter whether it's a typo -- ignored. This has been true of every document in this working group that he has edited. In the case of 4871-bis that means that I can have *no* input whatsoever, even though I guess all I can say is that amongst this group, there are lots of people who argue a lot, and yes, there are patterns to that, but nothing that in my opinion, based on list traffic and DKIM meetings etc. amounts to the kind of problem you mention above. More generally, and not really addressed to you Mike, but since this is that kind of message: I think it'd also be good if people could bear in mind that we're not saving or endangering the planet here - we're moving an RFC along the standards track by making very very minor changes and clarifications in a quite controlled fashion. (Most of which will be ignored by many coders;-) Some of the recent discussion seems, to me, quite overblown, (the volume of discussion absolutely definitely is), given the issues that are actually at stake. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304) wrote: And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. I view this from a Fault Analysis standpoint and the first thing to establish are your boundary conditions and it is difficult to have boundary conditions without a policy framework (or process expectations). Part of the modeling do include invalid signatures and we have shown that you can fold many of these invalid signature conditions into a single never signed condition. This why I continue to have a problem with the 4871 policy of transforming an invalid state point to never signed state point. It was fine when POLICY was still part of the framework. When we insisted on separating the two, that 4871 inherent policy should of been removed. This is not the first time, but I would love to re-issue the suggestion to remove that statement from 4871 iff we want to continue to separate policy into another layer. In that case, the higher layer needs all trace information available. The difference is that there is higher weight with deterministic boundary conditions when there is no real signature vs the indeterminate conditions with failed signatures. But depending on the domain expectation, these failed conditions can be folder to the no signature condition. I always come back to an image of an old patented idea of using a perfect circle to represent the optimal boundary conditions for a process. When that circle is skewed, you are off the optimal plane. It may not represent an emergency, but there is a shape or limits that tells you something is not right and alerts need to be signaled. For DKIM, we can only do this with Domain Expectations to help verifiers and local policy be molded. -- 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
[ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Friday, October 15, 2010 2:30 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: 1.4 Data Integrity A DKIM signature associates the d= name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the re-use of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed, and asserts nothing else about protecting the end-to-end integrity of the message. I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle. And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. Can someone name a current MUA that treats a DKIM-signed, malformed message differently from an unsigned one in terms of what it renders? If not, that last assertion is also false. And if the response to that is MUAs can change to show what was validated and what wasn't, then they can also change to handle the malformations we're talking about. And, in fact, that's probably easier to implement. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Friday, October 15, 2010 2:30 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. Does it? If the identifier is bound to the hashed information, I think it makes complete sense to believe one can make something of that content and it's relation to the identifier. It provides a stable identifier, but that identifier is inextricably tied to the signed content. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: 1.4 Data Integrity A DKIM signature associates the d= name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the re-use of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed, and asserts nothing else about protecting the end-to-end integrity of the message. I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle. And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified. Your proposed wording sounds a lot to me like what I think of as protecting the end-to-end content. I feel there's a lot of talking past each other here. If we were doing what you think of as protecting, what would be different? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 15, 2010 5:09 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. Does it? If the identifier is bound to the hashed information, I think it makes complete sense to believe one can make something of that content and it's relation to the identifier. It provides a stable identifier, but that identifier is inextricably tied to the signed content. There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name. Reputation, for example, would be checked against that, and not against the body hash or some other part of the message. The claim that it binds elements related to the RFC5322 header fields with the message body is the means of the algorithm, not the end. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: (I don't know what inapposite is, but I like it!) To your point, the identifier and the message must go together to be meaningful. One without the other is meaningless. Therefore one could argue that DKIM is protecting that relationship between the message and identifier. Or put another way, if a DKIM signer is taking responsibility for the message, then DKIM should also protect the original assertion of the signer - which again includes the message as well as the identifier. I don't think you can disconnect the two and retain value. Maybe that's what folk mean when they say protect the body? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
Murray S. Kucherawy wrote: There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name. Reputation, for example, would be checked against that, and not against the body hash or some other part of the message. That does not exclude any other functionalities. The claim that it binds elements related to the RFC5322 header fields with the message body is the means of the algorithm, not the end. But the associations are still binding. They are direct associations, especially 5322.FROM hence why author policy is still of interest for the framework (and a WG work product). I think these discussions get a little lost of how applications should be applied. The out of scope Reputation Application is just one of them, but it is not the only one. We got policy to work out at some point and thats a WG item. I posted this a while back but you will have input of various kinds for the various evaluators: DKIM_RESULT= DKIM_VERIFY(MSG) REP_RESULT = DKIM_REPUTATION(DKIM_RESULT, DKIM.D) POLICY_RESULT = DKIM_POLICY(DKIM_RESULT, MSG.FROM, DKIM.D) But these are not the only ones. You will see Expert System like designs take place or systems with flexible rule based scripting available to allow for local policy to be molded. For example, an expert rule can be: if a signature fails and has TESTING flag enabled, then see if he stilling testing after __12__ months then if so, negative classify this signer domain. I indicated a long time ago that we be careful with t=y flag and add guidelines track the usage. It was added. Note, I think the focus with signer domain is fine for trust but it must be recognize that there are other associations and efforts to minimize it, I don't think will be well accepted to the layman market place. Most will see what they see and DKIM signatures are passive extra information. All I like to distinguish is that attempting to only extract the valid signer domain as good useful information must be mirrored with its faults. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. Even without wildcards, there's been a variety of broken key records. I would hope it would be obvious that you have to assume that any data you haven't previously verified is potentially hostile, either deliberately or by mistake. This refers to DNS keys, DKIM signatures, and the message you're trying to sign or verify. By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. R's from PHL gate F18, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 7:13 PM, John Levine wrote: In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. Even without wildcards, there's been a variety of broken key records. I would hope it would be obvious that you have to assume that any data you haven't previously verified is potentially hostile, either deliberately or by mistake. This refers to DNS keys, DKIM signatures, and the message you're trying to sign or verify. By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? h=From with no From header is fairly well defined, I think. The message will be signed, and that signature will validate just fine, unless something in the message is modified - such as adding a From: field. I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
John Levine wrote: By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. For our DKIM implementation, it will fail to sign and fail to verify. -- 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: 3.6.2.1 - Working with other TXT records
Steve Atkins wrote: I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. -- 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: 3.6.2.1 - Working with other TXT records
On Oct 15, 2010, at 7:56 PM, Hector Santos wrote: Steve Atkins wrote: I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. h=From for a message that has no From: header when signed means that the message must have no From: header when the signature is validated, I think? And 5.4 just says you must include From in the h= tag, not that it must exist. A missing From: field makes the message not a 5322 message, but I'm not sure what that implies for DKIM. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM and patents
I found today this patent: US PATENT 7487217 http://www.docstoc.com/docs/57449330/Network-Domain-Reputation-based-Spam-Filtering---Patent-7487217 but then it seems prior art existed in the form of DKIM (which was started around 2004 http://news.domainmonster.com/dkim-email/) Not being a patent lawyer or anything like this, and knowing the US patent office gives anyone anything, I just wanted to point to this patent. May be also this has already been discussed a lot here... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: 4871bis - section 5.4/5.5 clarify 5322.From requirement
Steve Atkins wrote: Hector wrote: The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. h=From for a message that has no From: header when signed means that the message must have no From: header when the signature is validated, I think? And 5.4 just says you must include From in the h= tag, not that it must exist. A missing From: field makes the message not a 5322 message, but I'm not sure what that implies for DKIM. I see your point. Since a 5322.From is a required header for a valid RFC5322 message (From and Date are the two that required by RFC2822 and RFC5322, for RFC822, it requires the To (or BC) as well), I believe the expectation that it exist in the message for DKIM to imply it must exist in h=From. For our MDA/MSA, it will definitely invalidate an incoming message header but I don't recall the details. From old discussions in IETF-SMTP, I am pretty sure most MDA/MSA will enforce a 5322.From as well. I think the exception if when the client is local (internal) or maybe authenticated. The Alt-N DKIM API we are using will definitely fail to sign the message if a From is missing and it will fail to verify as well because there has to be a h=from and matching 5322.From. This probably means that it should clarified what that 5.4 sentence means and also the next section 5.5 5.5. Recommended Signature Content .. The following header fields SHOULD be included in the signature, if they are present in the message being signed: o From (REQUIRED in all signatures) It reads to me that From is the SHOULD exception to a MUST. But I can definitely see what you mean, because if it means that you have to add h=from without a real 5322.From, then a signature might be signed and be technical DKIM valid but only against those systems that are not enforcing a 5322.from header. -- 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
