Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
On Sep 16, 2010, at 5:58 AM, bill.ox...@cox.com bill.ox...@cox.com wrote: we can discuss it for the very reason you pointed out, people want to use/sell 3rd party signing, so lets discuss a policy and write it up. I know my company wants one and I suspect a few others might as well. I know that some folks fought very hard to keep it out originally but as I pointed out then, its time will come One of the original intentions behind publishing ADSP with only author domains was that we'd try that for a while, and then hopefully understand the ramifications well enough to devise a protocol that can handle non-author (non-From:) domains. Since that hasn't happened yet, is there another approach we could try for gaining this understanding? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
Concur, for all your reasons. From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman [ietf-d...@kitterman.com] Sent: Wednesday, September 15, 2010 9:56 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it. [...] - 1. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
Scott Kitterman wrote: My Technical recommendation. 1) For 4871bis, we should consider relaxing the 5322.From binding requirement from a MUST to a SHOULD. This will help justify its new words of separating the signer domain from the author domain. There is no separation until the 5322.From binding requirement is relaxed. As discussed during the original DKIM development effort, this is about protecting content from modification. The base DKIM spec already doesn't treat 5322.from specially, so such a change in not needed to meet your specified goal. Excuse me if I don't understand your reading. 5322.From is the only header that is required hashing. Is that not a special consideration? I think it will serve the community interest to find out why this large MTA vendor revised there open source software three years later presumably after extensive field operations to include a new option to relaxed the 5322.From binding. - 1. Thanks for your input. -- 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] RFC4871 5322.From Binding - Proposal to relax it.
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, September 16, 2010 12:57 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it. Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements. - 1. Scott K Make that a -2 for all the reasons Scott indicated. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
Since there's no such thing as a 3rd party signing policy in DKIM or ADSP, I don't understand why we're even discussing this. R's, John On Thu, 16 Sep 2010, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, September 16, 2010 12:57 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it. Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements. - 1. Scott K Make that a -2 for all the reasons Scott indicated. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor Please consider the environment before sending e-mail. 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] RFC4871 5322.From Binding - Proposal to relax it.
John R. Levine wrote: Since there's no such thing as a 3rd party signing policy in DKIM or ADSP, I don't understand why we're even discussing this. John, Because the lack of one has created other conflicts and mis-interpretations. Cited another way: 1) dkim=all is being read as a 3rd party signing allowance when as you say, offers no 3rd party signing policy. 2) It has created design pressure to create I-D proposals to hack the 5322.From or add new Headers to circumvent #1 3) As you often state, in the spirit of what counts most in the IETF, Running Code and open source DKIM API (which mean other MTA must be using it) naturally follows #1 4) Resigners (New and Legacy) are not listening to ADSP, so #1 doesn't apply, thus forcing #2 and #3. Just providing input to help codify the engineering. Thanks -- 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] RFC4871 5322.From Binding - Proposal to relax it.
On Thursday, September 16, 2010 03:23:15 am Hector Santos wrote: Scott Kitterman wrote: My Technical recommendation. 1) For 4871bis, we should consider relaxing the 5322.From binding requirement from a MUST to a SHOULD. This will help justify its new words of separating the signer domain from the author domain. There is no separation until the 5322.From binding requirement is relaxed. As discussed during the original DKIM development effort, this is about protecting content from modification. The base DKIM spec already doesn't treat 5322.from specially, so such a change in not needed to meet your specified goal. Excuse me if I don't understand your reading. 5322.From is the only header that is required hashing. Is that not a special consideration? I think it will serve the community interest to find out why this large MTA vendor revised there open source software three years later presumably after extensive field operations to include a new option to relaxed the 5322.From binding. Finding out why sounds reasonable. What you propose isn't finding out why, but assuming it's valuable without bothering to find out. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
John, we can discuss it for the very reason you pointed out, people want to use/sell 3rd party signing, so lets discuss a policy and write it up. I know my company wants one and I suspect a few others might as well. I know that some folks fought very hard to keep it out originally but as I pointed out then, its time will come On Sep 16, 2010, at 8:50 AM, John R. Levine wrote: Since there's no such thing as a 3rd party signing policy in DKIM or ADSP, I don't understand why we're even discussing this. R's, John On Thu, 16 Sep 2010, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, September 16, 2010 12:57 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it. Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements. - 1. Scott K Make that a -2 for all the reasons Scott indicated. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor Please consider the environment before sending e-mail.smime.p7sATT1..txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, September 16, 2010 8:08 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it. I think it will serve the community interest to find out why this large MTA vendor revised there open source software three years later presumably after extensive field operations to include a new option to relaxed the 5322.From binding. Finding out why sounds reasonable. What you propose isn't finding out why, but assuming it's valuable without bothering to find out. We have extensions that go beyond DKIM and ADSP in OpenDKIM. Lots of 'em. They generally fall into two categories (and some fall into both): One category is local policy stuff. These are decisions made about message handling after the DKIM evaluation is complete. They are well outside the scope of DKIM and ADSP, but they are generally useful to administrators. They aren't there to make any indication that a part of the protocol was broken, because in fact they have little if anything to do with the protocol. The other is experimental code. These are things that we thought might be useful, some of which do adjust the actual DKIM processing beyond what the RFC says, and are presented with a We think you might want/need/like this. Try it out if you want, and let us know if you like it. Such feedback, when we get it, is returned to the working group as input to the process. Neither class of extension is a statement by us that extensive field operations has yielded this as a flaw in the protocol or a required extension. Absent a statement by this other open source project to that effect, I would just assume it's another knob people can try. Since I'm pretty sure we're talking about Alt-N here, I'll ask them. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
Based on existing open source DKIM API code from a large MTA, they must of come across signatures that did not include the 5322.From signature binding requirement of RFC 4871 because it contains an option to not enforce 5322.From hash binding in the DKIM.H header. In other words, if the DKIM-Signature h= header does not have the from value, then this code has an option to ignore this RFC 4871 requirement and allow this type of DKIM-Signature. Although the API is technically violating RFC 4871, they must of did this for a reason but I am not totally clear what all scenarios this will cover with Author Domains who sign without the 5322.From bind. The main point is they found an implementation reason to add an verification option to relax the RFC 4871 MUST hash 5322.From requirement. My Technical recommendation. 1) For 4871bis, we should consider relaxing the 5322.From binding requirement from a MUST to a SHOULD. This will help justify its new words of separating the signer domain from the author domain. There is no separation until the 5322.From binding requirement is relaxed. 2) We should consider a 5617bis (ADSPbis) to codify its semantics regarding Author Domain only signature policies to include a: Always sign by *anyone* Policy. Currently 5617 (ADSP) defines the two policies: all All mail from the domain is signed with an Author Domain Signature. discardable All mail from the domain is signed with an Author Domain Signature Many people felt we were missing the Signed by Anyone concept which did not help authorized 3rd party signers or the list servers who are going to be resigning. To compensate, many viewed ADSP=ALL to mean it allowed any signer, not just the Author Domain as defined by the spec. In fact, this same DKIM API includes ADSP support and it also interprets ADSP=ALL as an anyone can sign concept as long as there is a valid signature. There is no option in the software to follow ADSP=ALL exactly how it it defined in 5871. Since this is an API from a large MTA vendor, I would not ignore this implementation data point. If the suggestion is made the software is buggy then we are back to a status quo of non-resolution of conflicting issues regarding the author domain, 3rd party signers and/or list servers. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com -- 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] RFC4871 5322.From Binding - Proposal to relax it.
2) We should consider a 5617bis (ADSPbis) to codify its semantics regarding Author Domain only signature policies to include a: Always sign by *anyone* Policy. Currently 5617 (ADSP) defines the two policies: all All mail from the domain is signed with an Author Domain Signature. discardable All mail from the domain is signed with an Author Domain Signature Many people felt we were missing the Signed by Anyone concept which did not help authorized 3rd party signers or the list servers who are going to be resigning. To compensate, many viewed ADSP=ALL to mean it allowed any signer, not just the Author Domain as defined by the spec. So, that would mean that anyone is allowed to spoof my 5322.From address, provided that they sign the message, would it? I'm not sure I could think of a useful application for that feature. Perhaps ADSP=anyof:example.com, example.org... would make the system more useful. Heck, one might even say anyof:*, if one really wanted. In fact, this same DKIM API includes ADSP support and it also interprets ADSP=ALL as an anyone can sign concept as long as there is a valid signature. There is no option in the software to follow ADSP=ALL exactly how it it defined in 5871. Since this is an API from a large MTA vendor, I would not ignore this implementation data point. If the suggestion is made the software is buggy then we are back to a status quo of non-resolution of conflicting issues regarding the author domain, 3rd party signers and/or list servers. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com -- 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] RFC4871 5322.From Binding - Proposal to relax it.
Ian Eiloart wrote: 2) We should consider a 5617bis (ADSPbis) to codify its semantics regarding Author Domain only signature policies to include a: Always sign by *anyone* Policy. Currently 5617 (ADSP) defines the two policies: all All mail from the domain is signed with an Author Domain Signature. discardable All mail from the domain is signed with an Author Domain Signature Many people felt we were missing the Signed by Anyone concept which did not help authorized 3rd party signers or the list servers who are going to be resigning. To compensate, many viewed ADSP=ALL to mean it allowed any signer, not just the Author Domain as defined by the spec. So, that would mean that anyone is allowed to spoof my 5322.From address, provided that they sign the message, would it? I'm not sure I could think of a useful application for that feature. Perhaps ADSP=anyof:example.com, example.org... would make the system more useful. Heck, one might even say anyof:*, if one really wanted. Perhaps and this has been proposed in the 2006 DSAP I-D, Doug's has similar TPA (Third Party Authorization) and I recently tried to rewake the DSAP idea for ADSP as an extension called ASL (Allowable Signer List). ADSP allows extension, so a DNS record like DKIM=all; x-asl=mipassoc.org, gmail.com would say, that I sign all my mail, and allow those other domains to also sign. However, this can be potentially be a high overhead/management for large companies with many employees using different list servers. I think it fits the millions more market place of small to mid size domains or private domains that may outsource a one or more third party signers or use a few professional or trade support list forums. If you think this is something to pursue, +1 it because I am trying to see if its worth the effort to reintroduce it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
Perhaps and this has been proposed in the 2006 DSAP I-D, Doug's has similar TPA (Third Party Authorization) and I recently tried to rewake the DSAP idea for ADSP as an extension called ASL (Allowable Signer List). ADSP allows extension, so a DNS record like DKIM=all; x-asl=mipassoc.org, gmail.com would say, that I sign all my mail, and allow those other domains to also sign. However, this can be potentially be a high overhead/management for large companies with many employees using different list servers. Too true, and I don't think that this kind of delegation would be any kind of a solution for the ADSP=discardable/MLM problem. It might be used as a work around for small vanity domains, but wouldn't scale. Plus, I'm not sure that it would be a great workaround, as it kind of says if you want to spoof my email address, here's a list of MLM servers that might accept my email and apply a convincing signature for you! think it fits the millions more market place of small to mid size domains or private domains that may outsource a one or more third party signers or use a few professional or trade support list forums. If you think this is something to pursue, +1 it because I am trying to see if its worth the effort to reintroduce it. -- 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] RFC4871 5322.From Binding - Proposal to relax it.
Hector Santos hsan...@isdg.net wrote: Based on existing open source DKIM API code from a large MTA, they must of come across signatures that did not include the 5322.From signature binding requirement of RFC 4871 because it contains an option to not enforce 5322.From hash binding in the DKIM.H header. I don't think that's a reasonable conclusion do draw from this data point. In other words, if the DKIM-Signature h= header does not have the from value, then this code has an option to ignore this RFC 4871 requirement and allow this type of DKIM-Signature. Although the API is technically violating RFC 4871, they must of did this for a reason but I am not totally clear what all scenarios this will cover with Author Domains who sign without the 5322.From bind. Protecting messages from in transit modification was one of the DKIM design goals. Excluding this user visible header from such protections is not a good idea. This is an even worse idea than l=. The main point is they found an implementation reason to add an verification option to relax the RFC 4871 MUST hash 5322.From requirement. People implement all kinds of thing for all kinds of reasons. Don't depend very much on the mere fact of an implementation tidbit. My Technical recommendation. 1) For 4871bis, we should consider relaxing the 5322.From binding requirement from a MUST to a SHOULD. This will help justify its new words of separating the signer domain from the author domain. There is no separation until the 5322.From binding requirement is relaxed. As discussed during the original DKIM development effort, this is about protecting content from modification. The base DKIM spec already doesn't treat 5322.from specially, so such a change in not needed to meet your specified goal. 2) We should consider a 5617bis (ADSPbis) to codify its semantics regarding Author Domain only signature policies to include a: Always sign by *anyone* Policy. Currently 5617 (ADSP) defines the two policies: all All mail from the domain is signed with an Author Domain Signature. discardable All mail from the domain is signed with an Author Domain Signature Many people felt we were missing the Signed by Anyone concept which did not help authorized 3rd party signers or the list servers who are going to be resigning. To compensate, many viewed ADSP=ALL to mean it allowed any signer, not just the Author Domain as defined by the spec. In fact, this same DKIM API includes ADSP support and it also interprets ADSP=ALL as an anyone can sign concept as long as there is a valid signature. There is no option in the software to follow ADSP=ALL exactly how it it defined in 5871. It sounds to me like a bug. Since this is an API from a large MTA vendor, I would not ignore this implementation data point. If the suggestion is made the software is buggy then we are back to a status quo of non-resolution of conflicting issues regarding the author domain, 3rd party signers and/or list servers. Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements. - 1. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
