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 John R. Levine > Sent: Wednesday, October 13, 2010 10:49 PM > To: dcroc...@bbiw.net > Cc: DKIM List > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > What you are calling for would be good to have. It should be done. > > Just not in the signing spec. > > Correct me if I'm wrong, but I hear you saying that if one creates or > verifies the DKIM signature on a message, one should also do the double > header check somewhere in the mail processing path, but rather than > saying so in the spec, it'll just be our private bit of folklore. I'm completely okay with providing informative guidance to signers and verifiers, or even to receivers and MUAs, maybe even right in the bis document. But once it becomes normative, and especially if we want to put a MUST in there, we're requiring the work of enforcing the terms of a non-DKIM RFC into DKIM. Any way you slice it, that just sounds like bad engineering to me. If we accept the model that DKIM is a layer that sits on top of the mail layer (and by that I mean RFC5322; SMTP is a layer below that even), then what crosses the layer boundary should only be valid, in the same way that only valid IP packets get passed up to the TCP layer, or only valid and sequenced TCP packet payloads make it up into a socket's read buffer, or only a valid SMTP command sequence can cause something to land in your inbox. The mail layer shouldn't pass crap upwards; and in this case that means an MTA shouldn't invoke a DKIM library/function/whatever unless the data it's about to pass across that line is known to be valid for that transition. The mail layer is where RFC5322 is implemented, so it has the code to do what you called the full body cavity search already, and so any lightweight header counting is thus by definition not only cheap, but actually redundant. It should be perfectly fine to say DKIM expects valid input, for whatever definition of that we want to invent, and also state that handing it anything else has either undefined results or specific bad results. I can point out dozens of UNIX man pages that say the same thing. It's not a new idea. In a C program, if I ask you to hand me a valid string, I'm saying something that has a specific, unambiguous, well-documented meaning. If despite that you hand me something that may or may not be a valid string, it's unreasonable for you to expect me or other possible handlers of that data to do something valid or safe with it every time. Indeed, the result could often be catastrophic. That MUAs or post-DKIM filtering agents might make weak, lazy or foolish rendering decisions is certainly unfortunate, perhaps even terrible, but I'm not convinced that all (or any) of the layers below that need to do normative things that compensate for, accommodate, or fix everything that might make it up that far, protecting them from themselves, only to have them come up with yet another new way to be vulnerable later. As I said in another message, I realize once you're actually writing an application to do all of this then the interface lines can get quite mushy. But I don't believe the IETF should be in the business of producing standards track protocol specifications that define interface lines which are intentionally mushy. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
"John R. Levine" writes: > > DKIM support in an MUA? Yuck. > > It's likely to be a long time before any MUA I use does anything with > DKIM, since I am not a fan of filtering mail while reading it. An MUA does not have to do filtering in order to support DKIM. It could display the Authentication Results header, or take some action depending on whether there is a valid DKIM signature - in a similar way that some web browsers will turn the URL bar green when the site presents a valid 'extended validation' certificate. ___ 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/2010 12:46 AM, Tony Hansen wrote: > Another potential option is to remove g= entirely: I'd like to encourage our considering this strongly, for two reasons: 1. Pragmatic -- It's causing confusion and errors, while providing no significant value-add. 2. Theoretical -- The feature recruits receivers to enforce what really are matters of internal controls within the sender. It's one thing to recruit receivers to help deal with attacks by outsiders, but quite another to burden receivers with tasks that are within the signer's control. 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] Last call comment: Changing the g= definition
On 10/13/2010 1:52 PM, Jim Fenton wrote: > I propose removing section 3.6.1.1 in its entirety. Not only do I support this, but I think we can remove all references to DomainKeys, except for the obvious historical reference to its role as input to DKIM. At the time DKIM was developed, worrying about compatibility with, and transition from, DomainKeys was essential. Now it isn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:45 AM, SM wrote: > RFC 4871 discusses about DNS in various sections. Unfortunately, > there is no reference to the DNS specifications. OMG. As in, wow. I propose changing from: DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. to: DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message. This can be an author's organization, an operational relay or one of their agents. ... Note that the sentence is slightly modified, which is the reason I'm running this past the wg. It defers reference to "signing" domain until later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM support in MUAs
Graham Murray wrote: > An MUA does not have to do filtering in order to support DKIM. It could > display the Authentication Results header, or take some action > depending > on whether there is a valid DKIM signature - in a similar way that some > web browsers will turn the URL bar green when the site presents a valid > 'extended validation' certificate. I think this is a very bad idea. Many people with quite a bit of technical knowledge struggle to grasp what DKIM really does (I am, or used to be, among them). What is really does (cryptographically attach a domain name to an email) is of little value to the end user. Worse, there are plentiful examples where this may be misleading to the end user. Think of a phish with a valid DKIM signature (of the phisher's domain). Or an email DKIM-signed by Gmail from your friend who "is in London, had all his possessions stolen and asks if he can borrow $2000 ASAP"; the fact that Gmail signed the message doesn't make it any less likely that your friend's account hasn't been hacked into. I am not a psychologist, but I believe that to many an end user a valid signature will suggest the email should somehow be trusted. (Taking some action, such as putting a messages in an appropriate folder, or giving it a blue background, based on a valid DKIM signature of a valid domain is a different matter.) Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. ___ 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
Even though I supported the addition of wording on how to improve the compatibility with DomainKeys records, I would support removing the new proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to ask the question: Is it still worth changing that section into a WARNING for people upgrading from DomainKeys, saying to make darn sure that they REMOVE g=; in their old DNS records because of interoperability issues? So the question becomes: if we remove the section on how DKIM and DK can play nice together, 1) do we chop out all references to DomainKeys, or 2) do we keep a short warning on what needs to be changed in the DK record to make it work with DKIM? Tony Hansen On 10/14/2010 8:09 AM, Dave CROCKER wrote: > On 10/13/2010 1:52 PM, Jim Fenton wrote: > >> I propose removing section 3.6.1.1 in its entirety. >> > Not only do I support this, but I think we can remove all references to > DomainKeys, except for the obvious historical reference to its role as input > to > DKIM. > > At the time DKIM was developed, worrying about compatibility with, and > transition from, DomainKeys was essential. Now it isn't. > > d/ > ___ 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'm all for simplification of the specs (and software logic) to one protocol and not mix in old stuff. I know that DKEYS are still in the minds of implementations that do both, but I don't think that will be case as we move forward with new implementations and APIs (which will most likely be DKEYS stupid anyway). -- HLS Tony Hansen wrote: > Even though I supported the addition of wording on how to improve the > compatibility with DomainKeys records, I would support removing the new > proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to > ask the question: Is it still worth changing that section into a WARNING > for people upgrading from DomainKeys, saying to make darn sure that they > REMOVE g=; in their old DNS records because of interoperability issues? > > So the question becomes: if we remove the section on how DKIM and DK can > play nice together, 1) do we chop out all references to DomainKeys, or > 2) do we keep a short warning on what needs to be changed in the DK > record to make it work with DKIM? > > Tony Hansen > > On 10/14/2010 8:09 AM, Dave CROCKER wrote: >> On 10/13/2010 1:52 PM, Jim Fenton wrote: >> >>> I propose removing section 3.6.1.1 in its entirety. >>> >> Not only do I support this, but I think we can remove all references to >> DomainKeys, except for the obvious historical reference to its role as input >> to >> DKIM. >> >> At the time DKIM was developed, worrying about compatibility with, and >> transition from, DomainKeys was essential. Now it isn't. >> >> d/ >> > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > -- 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] Last call comment: Changing the g= definition
On 10/14/2010 9:05 AM, Tony Hansen wrote: >Is it still worth changing that section into a WARNING > for people upgrading from DomainKeys, saying to make darn sure that they > REMOVE g=; in their old DNS records because of interoperability issues? > > So the question becomes: if we remove the section on how DKIM and DK can > play nice together, 1) do we chop out all references to DomainKeys, or > 2) do we keep a short warning on what needs to be changed in the DK > record to make it work with DKIM? For pragmatic guidance text that is not essential for direct implementation, I'm finding myself increasingly fond of the idea of putting such wisdom into the Deployment document... 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
> to: > > title="Introduction"> > > DomainKeys Identified Mail (DKIM) permits a person, role, or > organization to claim some responsibility for a message by > associating a domain name target="RFC1034" /> with the message. This can be an author's > organization, an operational relay or one of their agents. > ... Well, just to create a bit more of a rat-hole, is there any chance you'd like to add a definitional link for the word "message" as well? It seems to me that much of our other discussion swims around that meaning. Is it what is sent, is it what's signed, is it what shows up in the MUA... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] removing the g= definition?
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. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ 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 8:09 AM, Dave CROCKER wrote: > > > On 10/13/2010 1:52 PM, Jim Fenton wrote: >> I propose removing section 3.6.1.1 in its entirety. > > Not only do I support this, but I think we can remove all references to > DomainKeys, except for the obvious historical reference to its role as input > to > DKIM. > > At the time DKIM was developed, worrying about compatibility with, and > transition from, DomainKeys was essential. Now it isn't. +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
On 10/14/2010 9:49 AM, Mark Delany wrote: > Well, just to create a bit more of a rat-hole, is there any chance > you'd like to add a definitional link for the word "message" as well? The easy and possibly sufficient answer is: RFC 5322. If more precision is required, then Section 3.5 of RFC 5322. Does anyone feel some other citation is necessary? Does anyone feel that the section number citation in 5322 is essential. (I only ask because adding a pure RFC citation to the opening sentence of the Introduction will be somewhat cleaner without it. DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message . This can be an author's organization, an operational relay or one of their agents. 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] layer violations, was detecting header mutations after signing
> It should be perfectly fine to say DKIM expects valid input, for > whatever definition of that we want to invent, and also state that > handing it anything else has either undefined results or specific bad > results. 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. DKIM is full of layer violations where it tells people how to sign and verify robustly. Sec. 5.3 tells signers to downcode 8-bit MIME, 6.1.2 has some fairly dubious assumptions about the structure of the DNS, 6.1.3 even tells verifiers to rewrite MIME separators. This seems an odd place to draw a line in the sand, and an unfortunate one if you believe that an important use of DKIM should be to whitelist mail from trusted signers. 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 Wed, 13 Oct 2010 17:34:32 +0100, Charles Lindsey wrote: > But full 100% RFC5322 checking is extremely tedious, and is more that we > actually need. > > What we want is more like > CHECK DKIM && CHECK RFC5322 headers included in h= tag --> > ACCEPT > where at least the CHECK RFC5322 counts the number of occurrences, > perhaps > a little more, but not worry about the more obscure checks such as LFCR > instead of CRLF. On further thought, I would make that: CHECK DKIM && CHECK RFC5322 headers included in h= tag --> ACCEPT ELSE CHECK FOR ADSP DISCARDABLE (maybe for ALL) where the ADSP should check ALL the From headers that are found (so I guess we need an RFC5617-bis too, since 5617 takes no account of multiple From headers. -- 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 10/14/2010 10:17 AM, John R. Levine wrote: > 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. > > DKIM is full of layer violations where it tells people how to sign and > verify robustly. Protocol specifications should require all of that actions that are essential to correct operation and none of the actions that are not. A DKIM signature verifies or it doesn't. It delivers a signing domain or it doesn't. What is essential is that it perform the task of validating and delivering a signing domain that is associated with a collection of bits. Anything that defines how to do this is essential. Anything that can make this break needs to be covered, especially if there are ways to protect against the breakage. Perhaps surprisingly, having redundant header fields does not make DKIM break. And it is an issue outside of DKIM and, therefore, need not be "protected against" by DKIM. Also surprisingly, the same holds for more general message conformance checking. The checking does not make DKIM work, and it does not make it work better or worse. So it isn't needed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey >> Sent: Wednesday, October 13, 2010 9:12 AM >> To: DKIM >> Subject: Re: [ietf-dkim] detecting header mutations after signing >> >> The bad guy (the phisher) provides two From headers, but only signs one >> which, as DKIM is currently defined, has to be the second one. >> >> His two headers are: >> >> From: i...@ebay.com >> From: i...@phisher.com >> >> BUT many/most MUAs currently display only the first From header if two >> are >> provided. There is no reason why the verifier at the boundary should >> report an invalid signature, so the message gets through to the intended >> victim who just sees what his MUA shows him, which apparently is a >> message from the genuine ebay address. > > This is true if the message is not DKIM-signed at all. The rendering > choice you're highlighting here already exists in many/most MUAs. 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'. Note that RFC5617 is ambiguous as to which of the two From headers it will use to establish the Author Domain, so we are going to need a 5617-bis to fix that. > > If we can extract DKIM from the equation entirely and the problem > remains, how is it a DKIM problem? Since the phisher is trying to bypass that ADSP 'discardable' for ebay.com (and he thinks ADSP checkers might use the first address), it is in his interest to DKIM-sign the message himself (so that ADSP is never consulted). And that is why it is a DKIM problem, and why the loophole must be closed. -- 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
> What is essential is that it perform the task of validating and delivering a > signing domain that is associated with a collection of bits. Anything that > defines how to do this is essential. Anything that can make this break needs > to > be covered, especially if there are ways to protect against the breakage. But isn't the problem that the signing domain is being incorrectly associated with a different collection of bits? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, 13 Oct 2010 19:27:29 +0100, Jeff Macdonald wrote: >> If we can extract DKIM from the equation entirely and the problem >> remains, how is it a DKIM problem? > > > I agree with this. > > And even if there was a DKIM signature, it is the BAD GUY'S signature, > which should cause it to go into the SPAM folder, with a large > phishing warning. No, the Bad Guy has used a throwaway domain which has not yet made its way into any blacklist the SPAM checker might have been using. > > Count me as one of those who was confused early on about what DKIM > provides. DKIM seems to make assurances to message integrity. But it > doesn't. I think the reason why many think it does is because of the > body hash. It is trying to do to much. It should just provide an > identifier that can be verified. Instead of using the body for > hashing, use the Message-ID header along with the Date header and just > hash that. That way most folks would understand DKIM is just providing > an Identifier. > I have much sympathy with this rant; I think the body could have been handled much better. But it ain't going to change, and Barry has now declared it OT. -- 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, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: > > What is essential is that it perform the task of validating and delivering > > a > > signing domain that is associated with a collection of bits. Anything that > > defines how to do this is essential. Anything that can make this break > > needs to > > be covered, especially if there are ways to protect against the breakage. > > But isn't the problem that the signing domain is being incorrectly > associated with a different collection of bits? And just to elaborate on my own point. We went thru a lot of hand-wringing over canonicalization and the l= tag and so forth precisely because we were concerned about associating a signing domain with the wrong bits. But now it seems that making the wrong association is not treated with as much concern. If it is true that the DKIM effort is about associating an identifier with a collection of bits, it equally must be true that we want to make a similar effort to ensure that identifier is not associated with an unrelated collection of bits. Mark. ___ 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
Perhaps surprisingly, having redundant header fields does not make DKIM break. We must have some vastly different definition of "break". If allowing through modified messages that render very differently isn't broken, shouldn't we remove the advice against signing with l=0? The advice in favor of signing Subject: and To: fields? None of those has any technical effect on the ability of a verifier to compute and compare hashes. If not, what's the difference, other than the fact that we thought of some of them several years ago and just noticed these last week? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ 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/14/2010 07:58 AM, John R. Levine wrote: >> Perhaps surprisingly, having redundant header fields does not make >> DKIM break. > > We must have some vastly different definition of "break". > > If allowing through modified messages that render very differently isn't > broken, shouldn't we remove the advice against signing with l=0? The > advice in favor of signing Subject: and To: fields? None of those has > any technical effect on the ability of a verifier to compute and compare > hashes. There is an enormous difference between the situations with DKIM and, say, TLS+X509. With TLS, you take the output of the checks and use THAT ALONE to decide to deliver the bits or not. DKIM has *never* been such a protocol: there is a vast backstop of security infrastructure where DKIM is a just helper. Like I said, give spam/phishing filter writers some credit. They are not idiots. 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
SM wrote: > That text adds a requirement in an informative note. > >> My proposal to add more informative notes to help minimize this for >> the systems with the lack of DNS admin expertise on board. In >> particular for those with currently one existing need for a TXT record >> and that is SPF and incorrectly believe since its a TXT record, adding >> the DKIM public key data to it will work. > > There is an assumption that people managing DNS zones will have a basic > understanding of DNS. I don't think that the DKIM specification should > get into badly designed GUIs. > > RFC 4871 discusses about DNS in various sections. Unfortunately, there > is no reference to the DNS specifications. 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. -- HLS ___ 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
agreed On Oct 14, 2010, at 8:09 AM, Dave CROCKER wrote: > > > On 10/13/2010 1:52 PM, Jim Fenton wrote: >> I propose removing section 3.6.1.1 in its entirety. > > Not only do I support this, but I think we can remove all references to > DomainKeys, except for the obvious historical reference to its role as input > to > DKIM. > > At the time DKIM was developed, worrying about compatibility with, and > transition from, DomainKeys was essential. Now it isn't. > > d/ > -- > > 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] removing the g= definition?
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Dave CROCKER > Sent: Thursday, October 14, 2010 5:08 AM > To: IETF DKIM WG > Subject: Re: [ietf-dkim] removing the g= definition? > > On 10/14/2010 12:46 AM, Tony Hansen wrote: > > Another potential option is to remove g= entirely: > > I'd like to encourage our considering this strongly, for two reasons: > [...] I'd support this. Our statistics show that its use other than "g=*" or "g=" with DK back-compatibility is vanishingly small (when I looked last night, 7 out of 300,000 keys retrieved made use of it by actually naming something there). ___ 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 Dave CROCKER > Sent: Thursday, October 14, 2010 5:10 AM > To: IETF DKIM WG > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > On 10/13/2010 1:52 PM, Jim Fenton wrote: > > I propose removing section 3.6.1.1 in its entirety. > > Not only do I support this, but I think we can remove all references to > DomainKeys, except for the obvious historical reference to its role as > input to DKIM. +1 ___ 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 Dave CROCKER > Sent: Thursday, October 14, 2010 5:23 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records > > On 10/14/2010 12:45 AM, SM wrote: > > RFC 4871 discusses about DNS in various sections. Unfortunately, > > there is no reference to the DNS specifications. > > OMG. As in, wow. > [...] > to: > > title="Introduction"> > > DomainKeys Identified Mail (DKIM) permits a person, role, or > organization to claim some responsibility for a message by > associating a domain name target="RFC1034" /> with the message. This can be an author's > organization, an operational relay or one of their agents. > ... 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? ___ 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/14/2010 07:56 AM, Mark Delany wrote: > On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: >>> What is essential is that it perform the task of validating and delivering a >>> signing domain that is associated with a collection of bits. Anything that >>> defines how to do this is essential. Anything that can make this break >>> needs to >>> be covered, especially if there are ways to protect against the breakage. >> >> But isn't the problem that the signing domain is being incorrectly >> associated with a different collection of bits? > > And just to elaborate on my own point. We went thru a lot of > hand-wringing over canonicalization and the l= tag and so forth > precisely because we were concerned about associating a signing domain > with the wrong bits. > > But now it seems that making the wrong association is not treated with > as much concern. > > If it is true that the DKIM effort is about associating an identifier > with a collection of bits, it equally must be true that we want to > make a similar effort to ensure that identifier is not associated with > an unrelated collection of bits. Mark, with a signed bunch of bits you get two prizes for the price of one: you know which bits are signed, and then you know which bits aren't. There is no ambiguity in the spec about which bits are signed, so we're quibbling about the ones that aren't. Isn't this where we want to have people's secret sauce take over? That is, we want MTA, MDA, and MUA's to take those two piece of information and make better decisions about, oh say, rendering? We already know that the DKIM spec alone is not going to force the hand of recalcitrant or uncaring MUA's, but it is potentially quite helpful to ones that are receptive. Unless there's *really* something they can't figure out without protocol help, I'm not sure what the point of this is. This double added From thing is trivial to detect with the current spec. Mike ___ 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: Thursday, October 14, 2010 7:32 AM > To: DKIM > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > This is true if the message is not DKIM-signed at all. The rendering > > choice you're highlighting here already exists in many/most MUAs. > > 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. ___ 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 Mark Delany > Sent: Thursday, October 14, 2010 7:38 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > But isn't the problem that the signing domain is being incorrectly > associated with a different collection of bits? By the verifier, or by the MUA? ___ 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
> Unless there's *really* something they can't figure out without protocol > help, I'm not sure what the point of this is. This double added From thing > is trivial to detect with the current spec. Well, yeah. That's why I don't understand why people are so opposed to a SHOULD saying they should. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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 John R. Levine > Sent: Thursday, October 14, 2010 7:59 AM > To: dcroc...@bbiw.net > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > If allowing through modified messages that render very differently > isn't broken, shouldn't we remove the advice against signing with l=0? > The advice in favor of signing Subject: and To: fields? None of those > has any technical effect on the ability of a verifier to compute and > compare hashes. > > If not, what's the difference, other than the fact that we thought of > some of them several years ago and just noticed these last week? The difference is that the Subject:, To: and l= advice don't dabble in the area of having to tell a DKIM implementer to enforce parts of other protocols. Adding a second From: makes the message format illegal. The other ones don't. ___ 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/14/2010 09:45 AM, John R. Levine wrote: >> Unless there's *really* something they can't figure out without protocol >> help, I'm not sure what the point of this is. This double added From thing >> is trivial to detect with the current spec. > > Well, yeah. That's why I don't understand why people are so opposed to a > SHOULD saying they should. 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. 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. Mike ___ 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
> The difference is that the Subject:, To: and l= advice don't dabble in the > area of having to tell a DKIM implementer to enforce parts of other protocols. > > Adding a second From: makes the message format illegal. The other ones don't. We're still talking past each other. You're right, it makes the message format illegal, but so what? Historically, there has been no reason for MUAs to enforce format compliance on incoming messages. I get the impression that people expect that to change. But why would it? "To catch stuff that DKIM chose not to" isn't very compelling. R's, John ___ 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
> 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? This is basically the same model as X509, except that X509 builds the credibity test into the protocol via CAs, rather than externally via something like VBR. R's, John ___ 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: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:07 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > Adding a second From: makes the message format illegal. The other > > ones don't. > > We're still talking past each other. You're right, it makes the > message format illegal, but so what? That makes it invalid input to any module that requires input to comply with RFC5322, pure and simple. > Historically, there has been no reason for MUAs to enforce format > compliance on incoming messages. I get the impression that people expect > that to change. But why would it? "To catch stuff that DKIM chose not > to" isn't very compelling. 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. ___ 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 14/Oct/10 00:22, Jim Fenton wrote: > 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. -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. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. Finally, it does make sense to duplicate fields in h= as stated in -02's 8.14, because that's the only way to guard against the exploit in case the destination's verifier is coded according to the previous protocol version. ___ 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/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. 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
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 12/Oct/10 17:47, Barry Leiba wrote: >> 3) Philosophical conflictive parenthetical sentence: >> > >> > (This can also be taken as a demonstration that DKIM is not designed >> > to support author validation.) > Yeh, that's the only part I agree on (though not with the reasoning > that follows). I'm ambivalent about having that parenthetical > statement in there. I'd like to see some consensus about whether to > leave it or keep it. +1 for leaving it, it is just distracting in that context. ___ 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 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. You don't have to do it that way in the source code to make it work properly if some other design makes sense for you, but that is the delineation that should appear in the normative parts of protocol specifications. I'm talking purely about specification here. I'm totally fine with one omnibus implementation that does everything from SMTP server right up to a webmail rendering if that's what you want to do. ___ 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
> 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. > 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. R's, John ___ 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/14/10 6:30 AM, Dave CROCKER wrote: > > On 10/14/2010 9:05 AM, Tony Hansen wrote: >> Is it still worth changing that section into a WARNING >> for people upgrading from DomainKeys, saying to make darn sure that they >> REMOVE g=; in their old DNS records because of interoperability issues? >> >> So the question becomes: if we remove the section on how DKIM and DK can >> play nice together, 1) do we chop out all references to DomainKeys, or >> 2) do we keep a short warning on what needs to be changed in the DK >> record to make it work with DKIM? > > For pragmatic guidance text that is not essential for direct implementation, > I'm > finding myself increasingly fond of the idea of putting such wisdom into the > Deployment document... On the other hand, we have a fair amount of guidance (in the form of informative notes) in the spec already, and having it here would make it more likely to be seen. This is short; we're talking about a couple of sentences here. -Jim ___ 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: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:45 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > 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. ...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? ___ 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
> 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. Well, now we're back to my question to Dave, what's the advantage of leaving that as folklore rather than putting it in the spec other than the warm theological feeling of somewhat preserving layer distinctions, except for all the places we already didn't? We're still not talking about changing the bits on the wire, nor of the handling of any valid 5322 message. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
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. 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. ___ 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: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:50 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > Well, now we're back to my question to Dave, what's the advantage of > leaving that as folklore rather than putting it in the spec other than the > warm theological feeling of somewhat preserving layer distinctions, except > for all the places we already didn't? Why does it have to be normative? Authentication-Results has no normative "watch out for weird input" SHOULDs or MUSTs, but instead has an extensive discussion of possible issues in its Security Considerations section. That's what secdir asked for, and I was fine with that. (It actually does have some normative MUA advice. Wonder how that happened.) Nobody's saying this has to be relegated to "folklore". We can put a gigantic treatise on this in an informative appendix making this the biggest RFC ever if it will make people feel better. I just don't think it can be reasonably made normative. ___ 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/14/2010 10:47 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: John R. Levine [mailto:jo...@iecc.com] >> Sent: Thursday, October 14, 2010 10:45 AM >> To: Murray S. Kucherawy >> Cc: DKIM List >> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations >> after signing >> >>> 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. > > ...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? Not to mention the false dilemma that this needs to be handled in the MUA exclusively. It doesn't. 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 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? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Alessandro Vesely wrote: > > Correct. And the way that it fails to verify is 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. -0.5. This is a kludge. Its good to help, possibly, existing systems that is capable of defining the N+1 h=from values in their setup. The problem is you don't know if they can. The real solution is to fix up section 5.4 general paragraph regarding signing and verifying the last header because it ignored the exception in regards to 5322.From which fundamentally there can only be one. It needs to add the exception clause to that paragraph or in a follow up paragraph. Both verifiers and signers MUST make sure its DKIM input, especially the headers it will bind, are technically correct. Only DKIM can do that to close legacy loopholes. The h=from:from "kludge" should be seen as a temporary solution until verifiers and signers catch up with the Double From problem. It can't depend on other mail bots to do this. -- 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
>>> 3) Philosophical conflictive parenthetical sentence:
>>> >
>>> > (This can also be taken as a demonstration that DKIM is not designed
>>> > to support author validation.)
>> Yeh, that's the only part I agree on (though not with the reasoning
>> that follows). I'm ambivalent about having that parenthetical
>> statement in there. I'd like to see some consensus about whether to
>> leave it or keep it.
>
> +1 for leaving it, it is just distracting in that context.
Clarifying an error I made in the original message: it should say
"I'd like to see some consensus about whether to REMOVE it or keep
it." And it looks like Alessandro is on the side of removing
("leaving") it.
Sorry for the confusing typo.
Barry
___
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
>> 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? Is this, perhaps, an issue that's confusing to non-native English speakers? If so, we should make sure we take that into account in how we phrase it. > 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. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] removing the g= definition?
+1 on removing "g=". 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 Thu, Oct 14, 2010 at 12:45 AM, SM wrote: > At 17:31 13-10-10, Hector Santos wrote: >>My proposal to add more informative notes to help minimize this for >>the systems with the lack of DNS admin expertise on board. In >>particular for those with currently one existing need for a TXT record >>and that is SPF and incorrectly believe since its a TXT record, adding >>the DKIM public key data to it will work. > > There is an assumption that people managing DNS zones will have a > basic understanding of DNS. I don't think that the DKIM > specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the "_domainkey" identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. 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. Barry, as participant ___ 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 9:05 AM, Tony Hansen wrote: > Even though I supported the addition of wording on how to improve the > compatibility with DomainKeys records, I would support removing the new > proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to > ask the question: Is it still worth changing that section into a WARNING > for people upgrading from DomainKeys, saying to make darn sure that they > REMOVE g=; in their old DNS records because of interoperability issues? > > So the question becomes: if we remove the section on how DKIM and DK can > play nice together, 1) do we chop out all references to DomainKeys, or > 2) do we keep a short warning on what needs to be changed in the DK > record to make it work with DKIM? I don't see the problem. If we just remove 3.6.1.1, then, yes, we have an issue with migration. If we remove g= altogether, then we remove the problem: ALL key records will be treated as though they had "g=*", which means that the problematic situation is treated just as it was in DK, and the key records are compatible. Or am I missing something? The only thing we're eliminating by removing g= is the ability to restrict a key record for use only by specific i= identifiers. And Murray's stats show that there are fewer than ten instances of that in some 300,000 samples -- well below any reasonable threshold of caring. Barry, as participant ___ 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/14/2010 11:54 AM, Barry Leiba wrote: > On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen wrote: >> Even though I supported the addition of wording on how to improve the >> compatibility with DomainKeys records, I would support removing the new >> proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to >> ask the question: Is it still worth changing that section into a WARNING >> for people upgrading from DomainKeys, saying to make darn sure that they >> REMOVE g=; in their old DNS records because of interoperability issues? >> >> So the question becomes: if we remove the section on how DKIM and DK can >> play nice together, 1) do we chop out all references to DomainKeys, or >> 2) do we keep a short warning on what needs to be changed in the DK >> record to make it work with DKIM? > > I don't see the problem. If we just remove 3.6.1.1, then, yes, we > have an issue with migration. > > If we remove g= altogether, then we remove the problem: ALL key > records will be treated as though they had "g=*", which means that the > problematic situation is treated just as it was in DK, and the key > records are compatible. > > Or am I missing something? No, that doesn't solve the problem for all of the implementations that are out there now that implement 4871. Removing g= is only going to make the situation even worse because you've now taken away the documentation. 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
"Barry Leiba" wrote: >On Thu, Oct 14, 2010 at 12:45 AM, SM wrote: >> At 17:31 13-10-10, Hector Santos wrote: >>>My proposal to add more informative notes to help minimize this for >>>the systems with the lack of DNS admin expertise on board. In >>>particular for those with currently one existing need for a TXT record >>>and that is SPF and incorrectly believe since its a TXT record, adding >>>the DKIM public key data to it will work. >> >> There is an assumption that people managing DNS zones will have a >> basic understanding of DNS. I don't think that the DKIM >> specification should get into badly designed GUIs. > >I agree, more generally, that the DKIM spec can't tell people the >right way to manage their DNS records. DKIM already separates its TXT >records with the "_domainkey" identifier, as SPF does with _spf. If, >given that separation, people still merge the TXT records and whatnot, >that problem's well beyond the scope of our work to fix. > >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. > >Barry, as participant > +1. Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis. 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
Barry Leiba wrote: > On Thu, Oct 14, 2010 at 12:45 AM, SM wrote: >> At 17:31 13-10-10, Hector Santos wrote: >>> My proposal to add more informative notes to help minimize this for >>> the systems with the lack of DNS admin expertise on board. In >>> particular for those with currently one existing need for a TXT record >>> and that is SPF and incorrectly believe since its a TXT record, adding >>> the DKIM public key data to it will work. >> There is an assumption that people managing DNS zones will have a >> basic understanding of DNS. �I don't think that the DKIM >> specification should get into badly designed GUIs. > > I agree, more generally, that the DKIM spec can't tell people the > right way to manage their DNS records. DKIM already separates its TXT > records with the "_domainkey" identifier, as SPF does with _spf. If, > given that separation, people still merge the TXT records and whatnot, > that problem's well beyond the scope of our work to fix. > > 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. I know you realize I was not advocating information on managing DNS records. But what happen today, is further evidence that even DNS administrators or software developers who are asked to write a WEB-BASED manager for their service to support SPF and now DKIM, are not aware of how mixing it is can be in conflict. All I ask is that possible a simple statement or sentence in that short section provide some insight regarding not mixing it up with other TXT records and that wildcards should not be used for other TXT records because this can fail the DKIM public key lookup. In this case, a customer is using Network Solutions and in their add TXT record, it doesn't allow a blank sub domain. The only way to do it is to have a subdomain: "* (ALL OTHERS)" domain: .xyz.com value: v=spf1 . Clearly, this a software bug and the customer called NS about how to get a non-wildcard SPF record because it was interfering with their new DKIM public and ADSP records setup. NS's (first level support) answer was (erroneous) - "not possible. It doesn't work that way." So sure, this has to be fixed by NS, but what I am saying is that ISP people will also be reading the specs too perhaps to see what is required to implement Web-based DNS Records Management tools with DKIM and SPF support and what I am proposing is helpful insight on the design guidelines that would avoid conflicts. BTW, the customer (a government newsletter bulk spammer) had to delete his SPF record to get our DKIM implementation running with verifiable signatures. With the conflict, they were getting dkim invalid signatures with selector DNS errors. I'm sure they will be many customers who may not want to delete their SPF record in order to get DKIM working. So my suggestion is to help avoid these potential conflicts. It is not about going deep into DNS management issues. Just the basic DKIM public key integration issues with existing TXT records. If you don't think that is possible, ok. I think it is, but... :) -- 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
Scott Kitterman wrote: > +1. > > Just as a note of clarification, SPF doesn't prefix TXT records, but I don't > think that affects the analysis. The Network Solutions DNS Records manager does not allow you to add a TXT record without a sub-domain, so to add one, you have to add * which when saved, it shows up as * (All Others) for the sub-domain column. For the new DKIM customer, we were assisting in adding the DKIM public key and ADSP records and this conflicted with the lookups return SPF records for all DKIM/ADSP record queries. Clearly, this is a problem with Network Solutions web tool. What I proposing is provide insight into potential conflicts with existing SPF (or other records) that might have a wild card associated with it. The audience will include ISPs that need guidelines as well and already have a SPF wizard or something or only allow * sub-domains to get a non-prefix domain query. These notes will help provide them and future implementations of DKIM DNS records support the insight to do it correctly. I hope DKIM is about catering to all sites small to large, not just large systems with DBA and DNS administrators. The insights should help adoptions without pains. -- 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
Barry Leiba wrote: > On Thu, Oct 14, 2010 at 12:45 AM, SM wrote: >> At 17:31 13-10-10, Hector Santos wrote: >>> My proposal to add more informative notes to help minimize this for >>> the systems with the lack of DNS admin expertise on board. In >>> particular for those with currently one existing need for a TXT record >>> and that is SPF and incorrectly believe since its a TXT record, adding >>> the DKIM public key data to it will work. >> There is an assumption that people managing DNS zones will have a >> basic understanding of DNS. �I don't think that the DKIM >> specification should get into badly designed GUIs. > > I agree, more generally, that the DKIM spec can't tell people the > right way to manage their DNS records. DKIM already separates its TXT > records with the "_domainkey" identifier, as SPF does with _spf. If, > given that separation, people still merge the TXT records and whatnot, > that problem's well beyond the scope of our work to fix. > > 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. I missed your statement above: ... as SPF does with _spf. SPF is a no prefix lookup. This is why it became a conflict because its possible domains are using wildcards and in at least in one case discovered today, Network Solutions does not allow you to add a TXT record without a sub-domain. You have to get around it with an asterisk (*) and it shows it as "All Others". Maybe related, but I have not checked, does 4871 talk about parsing multiple records looking for the "v=DKIM1" string? If not, then this is needs to be written about because if we don't want to see anything about wildcard SPF records, then we have implementations that will need to change their wares to only parse the v=DKIM1 string. -- 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] Last call comment: Changing the g= definition
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote: > On 10/13/2010 1:52 PM, Jim Fenton wrote: >> I propose removing section 3.6.1.1 in its entirety. > > Not only do I support this, but I think we can remove all references to > DomainKeys, except for the obvious historical reference to its role as input > to > DKIM. > > At the time DKIM was developed, worrying about compatibility with, and > transition from, DomainKeys was essential. Now it isn't. +1 We've done a surprisingly good job of getting the word out that DK is over and DKIM is the future. ___ 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 13, 2010, at 1:59 PM, Mark Delany wrote: > On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly > wrote: > >> Having said that, if an MUA is going to present an indication of >> "DKIM PASS" to the enduser, then a reasonable person would expect >> some relationship between what is "passed" and what is presented to >> the enduser. > > That makes sense. And at least one MUA already renders DKIM verified > mail differently. I would think such an MUA could take the additional > step of rendering verified payload differently too. > > I know we're not in the MUA business, but if DKIM makes no difference > to what an end-user finally sees, then it serves a very limited > purpose indeed. I'm looking forward to a draft on MUA considerations for DKIM. With all these opinions on the matter being expressed so adamantly, somebody must have already started one...right? ___ 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
Barry, there are crossing questions. This question came up in response to removing 3.6.1.1 totally separate from the question of removing g= altogether. If we remove 3.6.1.1 without removing g= altogether, the question below becomes pertinent. If we remove g= altogether, then we can remove 3.6.1.1 *along* with all the other references to g= within the document. Tony Hansen On 10/14/2010 2:54 PM, Barry Leiba wrote: > On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen wrote: > >> Even though I supported the addition of wording on how to improve the >> compatibility with DomainKeys records, I would support removing the new >> proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to >> ask the question: Is it still worth changing that section into a WARNING >> for people upgrading from DomainKeys, saying to make darn sure that they >> REMOVE g=; in their old DNS records because of interoperability issues? >> >> So the question becomes: if we remove the section on how DKIM and DK can >> play nice together, 1) do we chop out all references to DomainKeys, or >> 2) do we keep a short warning on what needs to be changed in the DK >> record to make it work with DKIM? >> > I don't see the problem. If we just remove 3.6.1.1, then, yes, we > have an issue with migration. > > If we remove g= altogether, then we remove the problem: ALL key > records will be treated as though they had "g=*", which means that the > problematic situation is treated just as it was in DK, and the key > records are compatible. > > Or am I missing something? > > The only thing we're eliminating by removing g= is the ability to > restrict a key record for use only by specific i= identifiers. And > Murray's stats show that there are fewer than ten instances of that in > some 300,000 samples -- well below any reasonable threshold of caring. > > Barry, as participant > ___ 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
>> Well, now we're back to my question to Dave, what's the advantage of >> leaving that as folklore rather than putting it in the spec other than the >> warm theological feeling of somewhat preserving layer distinctions, except >> for all the places we already didn't? > > Why does it have to be normative? I'd be perfectly happy with Jim's language which as I recall says something like signers SHOULD decline to sign messages with redundant headers and verifiers SHOULD decline to verify messages with unsigned redundant headers. This is an attack on DKIM, not on MUAs, so it's reasonable for DKIM to at least take a crack at dealing with it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
> No, that doesn't solve the problem for all of the implementations > that are out there now that implement 4871. Removing g= is only going > to make the situation even worse because you've now taken away the > documentation. I wouldn't be opposed to moving it to an appendix of deprecated features, if for nothing else to ensure that some future DKIM++ doesn't inadvertently reuse g= to mean something else. Since this particular feature is apparently used in about .0007% of signatures, I can't get too worked up about breaking stuff. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/14/2010 6:01 PM, Tony Hansen wrote: > If we remove g= altogether, then we can remove 3.6.1.1*along* with all > the other references to g= within the document. This double removal appears to produce the simplest acceptable result. I believe we have not seen significant objection to either removal. My sense is that we are ok to do the double removal, but maybe we haven't seen enough comment. 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/. 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] Last call comment: Changing the g= definition
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Dave CROCKER > Sent: Thursday, October 14, 2010 3:33 PM > To: Tony Hansen > Cc: IETF DKIM WG > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > 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/. OK by me. ___ 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 John R. Levine > Sent: Thursday, October 14, 2010 3:31 PM > To: Barry Leiba > Cc: IETF DKIM WG > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > > No, that doesn't solve the problem for all of the implementations > > that are out there now that implement 4871. Removing g= is only going > > to make the situation even worse because you've now taken away the > > documentation. > > I wouldn't be opposed to moving it to an appendix of deprecated features, > if for nothing else to ensure that some future DKIM++ doesn't > inadvertently reuse g= to mean something else. That seems OK to me too. ___ 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/14/10 3:30 PM, John R. Levine wrote: >> No, that doesn't solve the problem for all of the implementations >> that are out there now that implement 4871. Removing g= is only going >> to make the situation even worse because you've now taken away the >> documentation. > I wouldn't be opposed to moving it to an appendix of deprecated features, > if for nothing else to ensure that some future DKIM++ doesn't > inadvertently reuse g= to mean something else. Isn't that what the IANA registry is there to prevent? -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
>> if for nothing else to ensure that some future DKIM++ doesn't >> inadvertently reuse g= to mean something else. > > Isn't that what the IANA registry is there to prevent? I dunno. What does IANA do in cases like these? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On Oct 14, 2010, at 4:44 PM, John R. Levine wrote: >>> if for nothing else to ensure that some future DKIM++ doesn't >>> inadvertently reuse g= to mean something else. >> >> Isn't that what the IANA registry is there to prevent? > > I dunno. What does IANA do in cases like these? http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-5 I presume that "g" will never vanish from that table. 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
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Steve Atkins > Sent: Thursday, October 14, 2010 5:00 PM > To: DKIM List > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > http://www.iana.org/assignments/dkim-parameters/dkim- > parameters.xhtml#dkim-parameters-5 > > I presume that "g" will never vanish from that table. I've seen other registries that have a "status" column to indicate current/historic/deprecated/whatever. Maybe we should do that. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] 2 Day Collection Stats
This is a small 2 days collection break down of the signed mail coming in: - total msgs :67028 - dkim_sign : 1779 (2.7% signed) - dkim_pass : 89.9% - dkim_fail : 10.1% --25.9% : dkim_body_hash_mismatch --14.0% : dkim_signature_bad --37.6% : dkim_signature_bad_but_testing --15.2% : dkim_selector_dns_perm_failure -- 2.8% : dkim_selector_invalid -- 4.5% : dkim_selector_granularity_mismatch - ADSP domains: 10.7% (of the signed messages) --38.5% : unknown (78.2% Third Party) --61.5% : all (13.3% Third Party) -- 0.0% : discardable I should probably add a recording which of these has List-IDs, but I think the high body hash failures are most list systems. Its interesting to see such a high selector failure. I think the 2.8% invalid selector has to do with mix ups with SPF records. -- 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] Last call comment: Changing the g= definition
On 10/14/2010 6:30 PM, John R. Levine wrote: > I wouldn't be opposed to moving it to an appendix of deprecated features, > if for nothing else to ensure that some future DKIM++ doesn't > inadvertently reuse g= to mean something else. > > Since this particular feature is apparently used in about .0007% of > signatures, I can't get too worked up about breaking stuff. > I consider this to be a clarification on how to go about "removing g=". Tony ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Getting the word out (was: Last call comment: Changing the g= definition)
Hi JD, At 12:24 14-10-10, J.D. Falk wrote: >We've done a surprisingly good job of getting the word out that DK >is over and DKIM is the future. We're doing a heck of a job. :-) There is still some confusion between DomainKeys and DKIM. I still see people signing with DomainKeys. You can pick any of the possibilities below or add more: (i) DKIM means DomainKeys (ii) Large provide supports DomainKeys (iii) Appliance supports DomainKeys (iv) The name is more inspiring If one of the large provider would like to get the word out, I suggest that it removes the reference to DomainKeys in the recommendations that it publishes for postmasters. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
