Re: [ietf-dkim] Last call comment: Changing the g= definition
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER d...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Folks, The pattern is completely consistent, so I will take this as agreement to remove both. Anyone objecting very strongly needs to speak up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 08:28 AM, Dave CROCKER wrote: On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Folks, The pattern is completely consistent, so I will take this as agreement to remove both. Anyone objecting very strongly needs to speak up. I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Therefore, the consensus that goes into the document will reflect what the chairs see. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Friday, October 15, 2010 10:17 AM To: IETF DKIM WG Cc: Barry Leiba Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. I was threatened with legal action on the basis of tortious interference if I continued to disagree with one participant's technical arguments or professional conduct on this list. I have thus elected not to engage that person any further in any discourse whatsoever on the list absent a withdrawal of that threat and some kind of guarantee of future civility. I have serious doubts the IESG would find fault in that choice on appeal. The IETF has dealt severely with other participants that have taken that attitude in the past. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On Fri, Oct 15, 2010 at 1:17 PM, Hector Santos hsan...@isdg.net wrote: In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. You're certainly welcome to file an appeal, if you think there's been a procedural problem. The first step, of course, is to bring the issue to the attention of the chairs (which you have), and the next is to discuss it with the responsible AD (Sean). I'm actually pretty certain that neither Dave nor Murray is deleting your (or anyone's) messages outright, though I can't guarantee that they're reading everything you have (or anyone has) to say. This is meant as a general statement to all: you can increase the chances that people will read your posts if you post clearly, concisely, and calmly (the three Cs?), and avoid invective and excess. In any case, as I said in reply to Mike, the chairs are paying attention to the whole discussion, and we will be evaluating consensus fairly. Note that that still means that even if one or two people disagree with something, rough consensus might go against them. It also means that if other participants agree with the objections and say so, the consensus might go that way as well. Barry, as fair chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:32 AM, Barry Leiba wrote: I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Barry, would that it worked that way. I have on many occasions supplied text, alternative wording, etc, only be completely ignored because I'm in Dave's killfile. Editors with killfiles should not be editors. Period. It completely breaks down the working group process. It's particularly galling since I'm one of the AUTHORS and FIRST IMPLEMENTER of the spec under revision. Remove Dave immediately. Mike, I prefer this discussion remain public Therefore, the consensus that goes into the document will reflect what the chairs see. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
I was threatened with legal action [...] I understand why you posted this, but, please, let's not continue this sort of discussion on the list. Everyone, we're here to find consensus and develop specifications. Let's no one attack anyone else; let's work on cooperating. As a conference button I once had says: Calm down: it's only ones and zeroes. Barry, as stern chair (who could use some port about now) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/10 7:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Given the lack of (useful) deployment of g=, and the consensus to move away from using actual mailbox addresses in the local-part of i= (which means that g= is matching with, potentially, an opaque value), I support this. However, we still need to caution DKIM signers deploying DKIM that they need to make sure that their selector records don't contain empty g= values, because there will be verifiers that check g= for a very long time. As I said before, my preference is to put that advice directly in 4871bis, in order to make sure that it is seen. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
For the record, what you were told was that if your childish action of filtering me extended to telling others to filter me, that would be grounds for tort. Apparently, I am not the only one who feels the consensus process is being skewed by key editors filtering of WG Participants that don't always agree with with the direction or changes to the WG documents. While you have all the right to filter your WG mail, that doesn't sound like good IETF engineering with the requirement of being open minded. You being a key editor of the nearly all the documents know requires you to BACK OFF and take in all the input and try to block them in their inputs. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Friday, October 15, 2010 10:17 AM To: IETF DKIM WG Cc: Barry Leiba Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. I was threatened with legal action on the basis of tortious interference if I continued to disagree with one participant's technical arguments or professional conduct on this list. I have thus elected not to engage that person any further in any discourse whatsoever on the list absent a withdrawal of that threat and some kind of guarantee of future civility. I have serious doubts the IESG would find fault in that choice on appeal. The IETF has dealt severely with other participants that have taken that attitude in the past. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton Sent: Friday, October 15, 2010 10:25 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition Given the lack of (useful) deployment of g=, and the consensus to move away from using actual mailbox addresses in the local-part of i= (which means that g= is matching with, potentially, an opaque value), I support this. However, we still need to caution DKIM signers deploying DKIM that they need to make sure that their selector records don't contain empty g= values, because there will be verifiers that check g= for a very long time. As I said before, my preference is to put that advice directly in 4871bis, in order to make sure that it is seen. I think we'll need an IANA action to do the following: - add a column to the key tag registry indicating current status (and declare valid status values) - set a status for everything currently in the registry, including changing g= to obsolete And we need an informative appendix detailing that g= was removed for lack of deployment use, plus the cautionary point you just made. Does that sound right? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. Folks, (First rule of politics and legal trials: if you can't win on the substance, try to win on the process.) Since this is a formal forum and we're in the middle of a formal act (making a decision) and the mailing list is a formal record, I'm feeling compelled to correct two factual errors, in spite of the potential for this taking us down the rabbit hole: 1. I don't killfile. 2. I reviewed all mailing list postings in the thread that followed my query. d/ ps. However I happen to agree with Barry's note about requirements. But an inaccurate formal record warranted correcting. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 15/10/10 18:32, Barry Leiba wrote: I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. There's nothing that requires any participant to read the posts by any other participant -- although as a chair, I'd rather the editors did read all posts related to their documents -- but it's up to the chairs to evaluate consensus. Right. (Though having so much mail is almost as effective as a killfile;-) In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Therefore, the consensus that goes into the document will reflect what the chairs see. Indeed, S. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 11:19 AM, Dave CROCKER wrote: On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. Folks, (First rule of politics and legal trials: if you can't win on the substance, try to win on the process.) Chairs: I object to the ad hominem attack. In this case, it is a monkey trail, because Dave simply ignores (by kill file, or by whatever other means he chooses to employ) any suggestions of people he has assigned to his bozo filter, a filter purely of his own making, and not driving by any sort of working group consensus. This is why he is an extremely poor choice for being named editor, a choice that I objected to at the time for this very reason. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:45 AM, Stephen Farrell wrote: In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Stephen -- the issue here is the procedural one that Dave ignores *any* input *at all* from people he filters. It doesn't matter whether it's a typo -- ignored. This has been true of every document in this working group that he has edited. In the case of 4871-bis that means that I can have *no* input whatsoever, even though I'm one of the authors of 4871 and have made substantial contribution to the community with stats, running code, and general insight about what running DKIM was like in a large enterprise setting. I'm fine with Dave not liking me as an individual and choosing to ignore me, but not with an editor's hat on. If he can't put that aside as an editor, he should recuse himself and step down. Mike, nothing I say here makes any difference because of who gates the changes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 15/10/10 19:48, Michael Thomas wrote: On 10/15/2010 10:45 AM, Stephen Farrell wrote: In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Stephen -- the issue here is the procedural one that Dave ignores *any* input *at all* from people he filters. It doesn't matter whether it's a typo -- ignored. This has been true of every document in this working group that he has edited. In the case of 4871-bis that means that I can have *no* input whatsoever, even though I guess all I can say is that amongst this group, there are lots of people who argue a lot, and yes, there are patterns to that, but nothing that in my opinion, based on list traffic and DKIM meetings etc. amounts to the kind of problem you mention above. More generally, and not really addressed to you Mike, but since this is that kind of message: I think it'd also be good if people could bear in mind that we're not saving or endangering the planet here - we're moving an RFC along the standards track by making very very minor changes and clarifications in a quite controlled fashion. (Most of which will be ignored by many coders;-) Some of the recent discussion seems, to me, quite overblown, (the volume of discussion absolutely definitely is), given the issues that are actually at stake. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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] 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
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] Last call comment: Changing the g= definition
On Thu, Oct 14, 2010 at 8:09 AM, Dave CROCKER d...@dcrocker.net 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] 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] 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] 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] Last call comment: Changing the g= definition
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen t...@att.com 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 Hansent...@att.com 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] 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] 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 Hansent...@att.com 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
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
-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
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
Re: [ietf-dkim] Last call comment: Changing the g= definition
If a v= value is not found at the beginning of the DKIM key record, the key record MAY be interpreted as for DomainKeys [RFC4870]. The definition given here is upwardly compatible with what is used for DomainKeys, with the exception of the g= value. In a DomainKeys key record, an empty g= value would be interpreted as being equivalent to DKIM's g=*. ... I'm not in favor of creating an ambiguity in the specification in order to accommodate a limited number of domains that can make a very simple correction to their key records. Especially when the majority of these domains are represented by a single email sending provider that obviously hasn't even taken the trouble to see whether their signatures verify. What, specifically would you like to have done with the text? Barry ___ 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 a v= value is not found at the beginning of the DKIM key record, the key record MAY be interpreted as for DomainKeys [RFC4870]. The definition given here is upwardly compatible with what is used for DomainKeys, with the exception of the g= value. In a DomainKeys key record, an empty g= value would be interpreted as being equivalent to DKIM's g=*. ... I'm not in favor of creating an ambiguity in the specification in order to accommodate a limited number of domains that can make a very simple correction to their key records. Especially when the majority of these domains are represented by a single email sending provider that obviously hasn't even taken the trouble to see whether their signatures verify. What, specifically would you like to have done with the text? I propose removing section 3.6.1.1 in its entirety. I thought we'd had this discussion before, and what's there was what we decided to do. Search facilities are inadequate for easy checking. I certainly think that pointing out the ambiguity issue is important, so I, as a participant, wouldn't want to remove it entirely. Allow me to suggest the following alternative text, and ask other participants to weigh in on which you prefer: 3.6.1.1. Compatibility Note for DomainKeys Key records for DKIM are backward-compatible with key records for the now-obsolete DomainKeys [RFC4870], except in one circumstance: DomainKeys interpreted an empty g= value to match any signing address (i= in the signature). In DKIM, that matching is done by g=*, or by omitting g= and taking the default behaviour. An empty g= value in DKIM will match only empty i= values. If a key record uses an empty g= value and also uses v=, the key record can be identified as belonging to DKIM, and the DKIM interpretation will be used. Absent a v= tag, though, the verifier cannot tell whether the signer intended the DomainKeys interpretation or the DKIM one. To avoid second-guessing in a security context, and because DomainKeys is an obsolete protocol, DKIM verifiers MUST interpret this situation in DKIM terms, matching only empty i= values. 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Wednesday, October 13, 2010 3:46 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition Everyone, please weigh in on how you would like to see this issue resolved. Perhaps: 1. Say nothing. 2. Use Tony's text, which is in 4871bis now. 3. Use my text or some variant of it (and is it MUST, or SHOULD?). 4. Something else...? My first choice is to leave it as-is in 4871bis. The risks of the ambiguity seem slight to me, but I can see the argument for pushing for something that is very clean. Thus, my second choice is to delete 3.6.1.1 from -bis and not make any reference to interpretation of DK keys at all. -MSK ___ 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
At 13:03 13-10-10, Barry Leiba wrote: To avoid second-guessing in a security context, and because DomainKeys is an obsolete protocol, DKIM verifiers MUST interpret this situation in DKIM terms, matching only empty i= values. Changing the g= definition takes advancement of the base DKIM protocol off the table. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
