Subject: [ietf-dkim] Last call comment: Changing the g= definition

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 21:53:06 -0700

This is a comment on the new section 3.6.1.1, "Compatibility Note for 
DomainKeys", that suggests a different interpretation of the g= tag in 
the key record if the v= value is not present at the beginning of the 
record.  The section says:

    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=*".

For about the past year, I have been monitoring Cisco's DKIM 
verification and have collected data on verification and on verification 
errors.  An early summary of that effort is at 
http://blogs.cisco.com/security/common_errors_causing_dkim_verification_failures/

Between June 1 and September 1, 2010, Cisco received invalid signatures 
from 632 domains with "inapplicable keys" (meaning a g= mismatch). For 
comparison, during that same period we received valid signatures from 
33054 domains.  Of these 632 domains, 390 use the same selector name, 
which corresponds to the name of an email sending provider that has 
gotten these domains to publish key records for its use.  I have 
contacted this email sending provider twice to make them aware of the 
problem, but have apparently not succeeded in getting them to fix it.  
All they need to do is remove the g=; tag from the selector records and 
they will be compatible with both DomainKeys and DKIM.

Going back to the proposed change, it would create an ambiguity in the 
spec:  If a domain has a selector record with g=; and no v= tag, the 
verifier MAY return a pass result.  Or it MAY return a fail result.  We 
don't know what to expect; the result is undefined.  Signers are not 
well-served by mechanisms that don't consistently work.

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.

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 23:29:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Tuesday, October 12, 2010 9:53 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Last call comment: Changing the g= definition
> 
> 33054 domains.  [...]

We don't track selector names, but our numbers are for the last six weeks, during which time we saw 18198 unique signing domains and 370 unique domains that sent signatures which failed due to the same cause.  Very similar data.

> well-served by mechanisms that don't consistently work.

We're talking about a DomainKeys signer here though, not a DKIM signer.  Since we're trying to be accommodating to a protocol DKIM ultimately replaced, does it still create a problem?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 23:33:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, October 12, 2010 11:30 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Collected data (oops)

Oops, sorry for the bogus Subject: change.  Feel free to change it back to keep the thread consistent.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 12:53:05 -0400

>    equivalent to DKIM's "g=*".
...
> obviously hasn't even taken the trouble to see whether their signatures

What, specifically would you like to have done with the text?

Barry

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 10:42:26 -0700

[sticking with Murray's subject line so as not to create two thread 
breakages!]

> We're talking about a DomainKeys signer here though, not a DKIM signer.  Since we're trying to be accommodating to a protocol DKIM ultimately replaced, does it still create a problem?
I don't have any data on how many messages had DK signatures as well as 
DKIM signatures, but at least some do (I checked some I received). I 
don't quite understand your question.  The ambiguity that is created has 
to do with the DKIM result, not the DK result.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 10:52:42 -0700

> What, specifically would you like to have done with the text?

I propose removing section 3.6.1.1 in its entirety.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 10:53:24 -0700

> Sent: Wednesday, October 13, 2010 10:42 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Collected data
> 
> don't quite understand your question.  The ambiguity that is created
> has to do with the DKIM result, not the DK result.

With this change, a DKIM signature referencing a "g=" key might verify if the verifier elects to enable this backward compatibility feature.

Without this change (i.e. the more strict posture), a DKIM signature referencing a "g=" key won't verify ever.  But that's the same as an unsigned message.

The harm in the apparent ambiguity seems minimal; it's no worse than if the signature or key was completely malformed somehow.  So is the distinction important?

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 11:22:07 -0700

> The harm in the apparent ambiguity seems minimal; it's no worse than if the signature or key was completely malformed somehow.  So is the distinction important?

With this change, a message signed referencing one of these keys MAY 
verify.  Wouldn't a signer want to fix the problem anyway (remove the 
empty g=), in order to have their signatures verify more consistently?

It also adds more complexity to the specification and to 
implementations.  Besides, DK compatibility should become less of an 
issue with time since it is a legacy protocol.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 16:03:44 -0400

> 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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 17:39:18 -0400

> Clarifying question:  What does "this situation" (in the last paragraph)
> refer to:  the use of an empty "g=" value, or an empty "g=" value absent
> a "v=" tag?

The latter, the "can't tell" situation.  We can tweak the text to make
that clearer, if the WG wants this change.

Barry

On Wed, Oct 13, 2010 at 5:34 PM, Jim Fenton <[email-masked]> wrote:
>  On 10/13/10 1:03 PM, Barry Leiba wrote:
> Clarifying question:  What does "this situation" (in the last paragraph)
> refer to:  the use of an empty "g=" value, or an empty "g=" value absent
> a "v=" tag?
>
> -Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 14:42:05 -0700

> Sent: Wednesday, October 13, 2010 2:34 PM
> To: Barry Leiba
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
> 

A quick point of order here: This is based on errata #1532 which is "Held for Document Update".  Are we free to change the proposed semantics that are described there, which do allow for a back-compatibility interpretation?

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 14:34:15 -0700

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 18:21:03 -0400

> A quick point of order here: This is based on errata #1532 which is
> "Held for Document Update".  Are we free to change the proposed
> semantics that are described there, which do allow for a back-compatibility
> interpretation?

The errata are suggested changes; 4871 is silent on how to handle
this.  Whatever text we put in should clarify the handling.

Now, it's certainly true that our choice of text could constitute a
sufficient change to require another pass through Proposed Standard,
in which case we'd have to decide whether that really is the right
thing to do or not.  My sense is that it's not, but others might
differ.

We can argue about whether the MUST in my text would result in
recycling at PS, whether changing it to SHOULD would not (I'm pretty
sure that's the case), and which is the right thing to do.

My opinion on "right thing" is that because DK has past the end of its
life, it's not necessary to recycle at PS to deal with
DK-compatibility issues.

Barry, as participant (who happens to know the chairs)

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 18:46:08 -0400

> this.  Whatever text we put in should clarify the handling.

Further to this:
I've just located the discussion of erratum 1532 -- from 22 to 25
July, starting here:
   http://mipassoc.org/pipermail/ietf-dkim/2010q3/013778.html

Jim made the same objection then as he is now (surprise!: he's being
consistent), and we never resolved the issue.

We could leave it unresolved then, because we marked the erratum "hold
for document update."  But now it's document update time, so we have
to resolve it.

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...?

Barry, as chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 15:56:51 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Wednesday, October 13, 2010 3:46 PM
> To: IETF DKIM WG

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

---

From: SM <[email-masked]>
Date: Wed, 13 Oct 2010 15:36:35 -0700

>       interpret this situation in DKIM terms, matching only

Changing the g= definition takes advancement of the base DKIM 
protocol off the table.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 19:43:00 -0400

> issue with time since it is a legacy protocol.

+1

IMO, DKIM is already a "complex" technology to properly implement and 
integrate into a system, especially with key management. We decided 
not to deal with DomainKeys. We don't add it or verify it.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Tony Hansen <[email-masked]>
Date: Thu, 14 Oct 2010 00:46:50 -0400

> Changing the g= definition takes advancement of the base DKIM

Saying that a DKIM verifier must use DKIM semantics for a particular 
situation is not a change to the protocol.

Another potential option is to remove g= entirely:

    RFC 2026 section 4.1.2:
    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.
     ...
    A Draft Standard is normally considered to be a final specification,
    and changes are likely to be made only to solve specific problems
    encountered.
     section 6.2:
    A specification may be (indeed, is likely to be) revised as it
    advances through the standards track.  At each stage, the IESG shall
    determine the scope and significance of the revision to the
    specification, and, if necessary and appropriate, modify the
    recommended action.  Minor revisions are expected, but a significant
    revision may require that the specification accumulate more
    experience at its current maturity level before progressing. Finally,
    if the specification has been changed very significantly, the IESG
    may recommend that the revision be treated as a new document, re-
    entering the standards track at the beginning.

These clauses have usually been held to mean that removing troublesome 
options does not mean that a PS recycle is required.

     Tony Hansen

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 08:07:39 -0400

> 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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 08:09:52 -0400

> 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

---

From: Tony Hansen <[email-masked]>
Date: Thu, 14 Oct 2010 09:05:27 -0400

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

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 09:20:26 -0400

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 09:30:21 -0400

On 10/14/2010 9:05 AM, Tony Hansen wrote:
>    Is it still worth changing that section into a WARNING

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

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 09:54:51 -0400

> 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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 14 Oct 2010 09:57:04 -0400

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: <[email-masked]>
Date: Thu, 14 Oct 2010 08:16:20 -0400

agreed

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:20:37 -0700

> From: [email-masked] [mailto:[email-masked]] 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?
> 
> [...]

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).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:21:10 -0700

> Sent: Thursday, October 14, 2010 5:10 AM
> To: IETF DKIM WG
> DomainKeys, except for the obvious historical reference to its role as
> input to DKIM.

+1

---

From: Jim Fenton <[email-masked]>
Date: Thu, 14 Oct 2010 10:44:44 -0700

> finding myself increasingly fond of the idea of putting such wisdom into the

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:43:33 -0400

+1 on removing "g=".

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:54:39 -0400

> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 12:01:35 -0700

On 10/14/2010 11:54 AM, Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen<[email-masked]>  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.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 14 Oct 2010 12:24:43 -0700

+1

We've done a surprisingly good job of getting the word out that DK is over and DKIM is the future.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 14 Oct 2010 18:01:44 -0400

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

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 18:30:37 -0400

> to make the situation even worse because you've now taken away the

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,

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 18:33:20 -0400

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 15:37:18 -0700

> Sent: Thursday, October 14, 2010 3:33 PM
> To: Tony Hansen
> Cc: IETF DKIM WG

OK by me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 16:04:46 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Thursday, October 14, 2010 3:31 PM
> To: Barry Leiba
> Cc: IETF DKIM WG

That seems OK to me too.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 14 Oct 2010 16:18:41 -0700

> inadvertently reuse g= to mean something else.

Isn't that what the IANA registry is there to prevent?

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 19:44:24 -0400

> Isn't that what the IANA registry is there to prevent?

I dunno.  What does IANA do in cases like these?

Regards,

---

From: Steve Atkins <[email-masked]>
Date: Thu, 14 Oct 2010 16:59:40 -0700

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 17:02:30 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, October 14, 2010 5:00 PM
> To: DKIM List

I've seen other registries that have a "status" column to indicate current/historic/deprecated/whatever.  Maybe we should do that.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 14 Oct 2010 20:43:09 -0400

> 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

---

From: SM <[email-masked]>
Date: Thu, 14 Oct 2010 22:04:45 -0700

Hi JD,
>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

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 15 Oct 2010 10:28:40 -0400

+1

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 11:28:23 -0400

On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER<[email-masked]>  wrote:
>>

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Oct 2010 10:01:25 -0700

> 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

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 13:17:29 -0400

> the echo chamber of his own making.

+1, this is what I have been calling "Consensus by Osmosis."

> 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.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Oct 2010 13:32:52 -0400

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 10:32:55 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Friday, October 15, 2010 10:17 AM
> To: IETF DKIM WG
> Cc: Barry Leiba

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.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Oct 2010 13:40:54 -0400

> 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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Oct 2010 10:40:52 -0700

> 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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Oct 2010 13:44:08 -0400

> 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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Oct 2010 10:25:06 -0700

>> a round of explicit reactions to the specific idea of removing /both/.

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 13:59:05 -0400

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 11:05:38 -0700

> Sent: Friday, October 15, 2010 10:25 AM
> means that g= is matching with, potentially, an opaque value), I
> support this.
> 

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?

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 14:19:21 -0400

On 10/15/2010 1:32 PM, Barry Leiba wrote:
>>     Dave killfile's
>> So I strongly object on procedural grounds
...
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Oct 2010 18:45:15 +0100

> 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

Indeed,
S.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Oct 2010 11:40:38 -0700

> 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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Oct 2010 11:48:57 -0700

> for an editor to try to close off things that seem to have a clear

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Oct 2010 14:31:54 -0700

On 10/14/10 6:54 AM, John R. Levine wrote:
> I agree, g= seems to me to be a vestige of the confusion between i= 
> and d= identity.
>
> If we do, it's probably a good idea to put in Tony's WARNING for 
> people upgrading from DK.
+1

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Oct 2010 23:49:41 +0100

On 15/10/10 19:48, Michael Thomas wrote:
> 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.