Subject: [ietf-dkim] A meta-note: stepping back from the feature discussion

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 15:48:10 -0700

Murray said in a previous discussion:

> Which means you're also given the option to know what the signer's  
> notion of the signature's validity time is.  And you're free to  
> ignore it too.
>
> If the signer doesn't provide it, the receiver has lost the choice  
> to ignore it or use it.
>
> I can't say for sure that anyone is or isn't using it, but I would  
> prefer not to remove flexibility that's there now even if it was  
> possibly a mistake for it to be there in the first place (unless of  
> course it's clearly harmful).

Stepping back for a moment, we have a number of questions that are on  
their surface reasonable questions.

For some set of features, should a given feature be removed?

That's reasonable to ask, but I realize from Murray's words that he's  
right in the general case as much as for the specific feature.

Standardization is a process of compromise. In the IETF, we pronounce  
compromise as "rough consensus." In any compromise or rough consensus,  
there are things that are controversies. For my purposes here, I will  
define "controversy" to be anything that is not unanimous.

Someone who likes a controversial thing can legitimately claim that  
these seemingly-reasonable questions are in fact a subversion of the  
process of rough consensus. Right now, I basically agree. We approved  
4871 only two years ago. That is *barely* one software development  
cycle. Anything that is present in 4871 as a part of rough consensus,  
should not fall out of 4871bis unless there's a *strong* consensus  
that it go away.

This is especially true for the features that are undeniably  
controversial. l= leaps to mind as undeniably controversial. Some  
people loathe it, some people love it. (I am, as I've always been, in  
the middle where I see both sides of that one.) But the fact that it  
is truly controversial is why is should stay. Removing a controversial  
feature because it is controversial flies at the very process of rough  
consensus, and I think we just shouldn't go there.

I thus now believe that if a feature is in 4871, it should stay in  
4871bis unless there is strong consensus to remove it. Surely there  
must be one or two of those, but the mere presence of a large  
discussion indicates that it needs to say.

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

---

From: hector <[email-masked]>
Date: Tue, 02 Jun 2009 22:43:35 -0400

+1  Jon.

I want to get my input and implementation considerations on these tags.  
Overall, optimized processing and lower receiver abuse are the goals.

T=

This is the only one I see that has no place in production ware and 
should not become a perpetuate tag used by a domains.  Unfortunately, 
since it is present in the specs,  it can't be ignored.   Our plan was 
to provide a local policy for a domain "t=y time period" that correlates 
to ongoing faults.  When first seen,  if the signature fails, the domain 
t=y domain will recorded. If it continues, then an operator option will 
be provided to flag it.   This tag was proposed to be remove long ago.  
I thought we had majority consensus on this during the threat analysis.

X=

Our plan was to use this as an fault optimizer. If present, it will help 
reduce DNS lookups and rehash overhead.  I refer to Mr. Thomas on this.

L=

This tag has useful ideas however it comes with some replay abuse 
potential but I don't think the handling can not be overcome..    It all 
depends on how receivers  provide operators the options to deal with 
fault overall.  If  used to promote abusive failure (i.e. bad guy is 
trying to force receivers to turn off DKIM, and uses T=Y as well) then 
domain policy if available can help here.  I personally think high value 
domains (banks, eCommerce with direct 1 to 1 communications with their 
users) will use it less, if at all, than list systems or some 
newsletter/ad emailer broadcasting 1 to many communications.    So I am 
on the fence on this, but I think it is a useful feature that can be 
used positively.  I vote to keep.

K=

I was expecting to use to key tag to serve as a preemptive safety 
feature for high value domains.  The idea is that the vendor wants to 
sign up a new customer and offer email as part of their business 
communications.   The vendor can ask the user for his email address and 
with the right tools provided, quickly do a lookup to see if the user's 
principal domain receiver supports DKIM and proper verification.  If 
not, the vendor might offer and assign their own special service domain 
email account or outsource the email service who can  provide secured 
communications between the vendor and the user. or they might just tell 
the user to get an gmail.com for their communications.   In short, the 
utility of tag will help proper expected interoperability.  If the 
user's domain does not support a newer or recommended hashing method, 
the high value domain vendor might not want to risk unsecured 
communications with the user.

--
HLS

Jon Callas wrote:
> ------------------------------------------------------------------------
>

---

From: SM <[email-masked]>
Date: Tue, 02 Jun 2009 22:45:50 -0700

At 15:48 02-06-2009, Jon Callas wrote:
>Stepping back for a moment, we have a number of questions that are 
>on their surface reasonable questions.

Most of the questions asked seem reasonable to me.  Having to answer 
them all is another question.

>For some set of features, should a given feature be removed?

It's two years too late to answer that.

>Standardization is a process of compromise. In the IETF, we 
>pronounce compromise as "rough consensus." In any compromise or 
>rough consensus, there are things that are controversies. For my 
>purposes here, I will define "controversy" to be anything that is 
>not unanimous.

Yes.  And some of the features that have been added were 
controversial at that time.  If we want our implementation to be RFC 
4871 compliant, we implement these features.  There is nothing that 
forces us to implement a feature we view as "bad".  We can even say 
that our implementation is RFC 4871 compliant but that doesn't make 
the implementation interoperable.

Regards,
-sm