Subject: [ietf-dkim] Why bother removing features?

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Jun 2009 12:29:56 +0200

Folks,

A fair question that I was just asked (again) is whether this are problems with 
the DKIM Signing specification that actually /require/ removing features?  The 
fact that this question persists probably warrants trying to answer it again...

It would be delightfully convenient to have well-document reports of serious 
problems that are caused by one feature or another.  Unpleasant, but convenient. 
Convenient because we would have a clear and compelling basis for knowing what 
to focus on.  (But, then, we probably wouldn't be able to consider going to 
Draft...)  Absent problem reports, we need to work a little harder, to 
understand what features should be considere for removal and why.

Absent problem reports, we are left with the question of features that simply 
are not being used.  By 'used' I mean that there is no indication of end-to-end 
activity and utility.  Signers might be exploiting one feature or another that 
validators are ignoring.  Or signers might not be using the feature at all.  I'm 
classing both as "unused".

The problem with retaining unused features is that it makes it more difficult to 
explain DKIM use, it adds to the cost of developing DKIM support, and it invites 
interoperability problems later.

1.  Explaining things

Since we are still seeking adoption by more email services, we still have a 
significant education task to perform.  This is both about the nature of DKIM 
and the particulars of using it.  And it is both for developers and for 
operators.  The latter especially need not just the value proposition but the 
operational impact, which means discussion of usage scenarios.

The more features in a protocol, the more difficult it is to explain how things 
work, due to combinatorial interactions.  Phrases like "use it however you want" 
do not help because operations folk need to be told the answer, not assigned the 
task of developing one.

At its core, DKIM is really rather simple:  Give the receiver a validated 
identifier that asserts a degree of responsibility for a message.  The 
validation is accomplished by signing the message body and some of the header 
fields.  The public key is in the DNS.  Done.

With its full set of additional features, DKIM's nature becomes potentially 
confusing and its operational use even more so.

2.  Unused feature are costly

Actually, of course, /all/ features are costly.  There is no such thing as an 
additional feature that is entirely free.  Each feature requires coding, testing 
(internally and with other implementations), documenting and (potentially) 
operations and support.  Unused features have the distinctive characteristic of 
developing no serious operational experience, so that the basis for documenting 
use is poor.  This leads to the next concern...

3.  Unused features invite interoperability problems long after initial adoption

Unused feature are like time-bombs.  No matter how diligent developers are, the 
usual interoperability shake-out for protocol code won't happen, because some of 
this requires real-world use.  So when (if) use finally starts happening, there 
is certain to be a round of interoperability problems.  Having this occur long 
after DKIM is adopted winds up making DKIM look unstable/unreliable.  Just the 
sort of thing one does not want ever, but especially for a security feature 
primarily targeted at email operations.

So, tight specifications that have only the core features, known to be needed, 
benefit from being easier to explain, cheaper to deploy and operate and safer in 
the long-run.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Thu, 11 Jun 2009 07:48:52 -0400

Remove unused features? Sure, adsp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Thursday, June 11, 2009 6:30 AM
To: DKIM IETF WG
Subject: [ietf-dkim] Why bother removing features?

Folks,

1.  Explaining things

d/
--

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 11 Jun 2009 21:28:06 +0530

>  Remove unused features? Sure, adsp

+1 for rm -rf adsp

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jun 2009 15:45:35 -0400

Come on, people: stop being snarky.
Dave asked a legitimate question about the DKIM base spec, which has
been Proposed Standard for two years now, and which we're considering
progressing to Draft Standard.

Whether you like ADSP or not, it isn't part of this.

Barry

---

From: <[email-masked]>
Date: Fri, 12 Jun 2009 09:34:18 -0400

Okay, I would like to keep what we have, removing pieces is not a good idea, people don't have to use the tags if they don't want to and we MAY have a need for them in the future. The tags were discussed at length during the original draft. Removing them after the fact doesn't help or hurt adoption rates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, June 11, 2009 3:46 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Why bother removing features?

Barry

---

From: Steve Atkins <[email-masked]>
Date: Fri, 12 Jun 2009 17:06:59 -0700

On Jun 12, 2009, at 6:34 AM, <[email-masked]> <[email-masked]>  
wrote:

> Okay, I would like to keep what we have, removing pieces is not a  
> good idea, people don't have to use the tags if they don't want to

Implementors have to, for DKIM verifiers at least. Also, even DKIM  
signers have to either understand the semantics of each and every tag,  
even if they don't use them, or ignore the spec and use a subset of  
possible configurations as advised by a third-party deployment document.

> and we MAY have a need for them in the future.

We may. Verifiers will need to support them pretty much forever  
whether we do or not, though. Also, in the case where the actual use  
of the flag is as part of an extension then there will need to be  
standards making and new development to actually use the flag, whether  
it's in the base spec or not.

> The tags were discussed at length during the original draft.  
> Removing them after the fact doesn't help or hurt adoption rates.

I've seen interop problems caused very recently by a deep  
misunderstanding of what g= is for and how it interacts with i=. "We  
tried DKIM and gmail / yahoo said our signatures were invalid" is  
hurting adoption by senders today, and I'm sure some of that is  
because of misunderstanding of what some of the more obscure flags are  
supposed to be used for.

Which subset of tags could be pruned (or even whether that's a zero  
size set) is a good question, but some of them are causing hurt today.

Cheers,
   Steve

---

From: SM <[email-masked]>
Date: Fri, 12 Jun 2009 21:24:01 -0700

>because of misunderstanding of what some of the more obscure flags are

I've seen interoperability problems with most of the features before 
RFC 4871 was published.  Even if those features are removed, there 
will still be people reporting invalid signatures with gmail and 
Yahoo.  That happened with DomainKeys and it happens to a lesser 
extent with DKIM.

There is some operational experience which allows a better 
understanding of what could go wrong.  We have seen slow adoption of 
DKIM for reasons which have not been discussed in this WG.  Even if 
these features are removed, it won't speed up adoption of DKIM as 
there is a missing link which is not part of the work of this WG.

Part of the problem is that most people do not understand how 
Internet Mail works in their environment, or to put it another way, 
DKIM imposes restrictions on how it should work.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 13 Jun 2009 07:51:33 -0400

[email-masked] wrote:
> Okay, I would like to keep what we have, removing pieces is not a good idea,
> people don't have to use the tags if they don't want to and we MAY have a
> need for them in the future. 

There is an infinite array of features that we may have need for in the future. 
  So that's not an encouraging line of argument for retaining any particular 
feature.

Features carry costs.

Perhaps you missed my earlier note, which touches on the significant costs of 
retaining unused features:

> Date: Thu, 11 Jun 2009 12:29:56 +0200
> From: Dave CROCKER <[email-masked]>
> To: DKIM IETF WG <[email-masked]>
...

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Sat, 13 Jun 2009 14:51:15 +0200

And beyond what Dave said, if a feature is unused you can't take it to 
draft.

Eliot

On 6/13/09 1:51 PM, Dave CROCKER wrote:
>> From: Dave CROCKER<[email-masked]>
>> To: DKIM IETF WG<[email-masked]>

---

From: Michael Thomas <[email-masked]>
Date: Sat, 13 Jun 2009 10:40:36 -0700

> Features carry costs.

   Removing features carry costs too.
> retaining unused features:

  Perhaps he just doesn't agree with you.

       Mike

---

From: <[email-masked]>
Date: Sat, 13 Jun 2009 11:33:17 -0400

Let me rephrase that
At my shop I see dkim everyday that uses all of the features provided. As a verifyer I dont use all of those features in my ruleset at present. These tags are being used rightly or wrongly in the wild by signers. Also note that spammers tend to properly use dkim as opposed to small email providers.
Bill Oxley
________________________________________
From: Eliot Lear [[email-masked]]
Sent: Saturday, June 13, 2009 8:51 AM
To: [email-masked]
Cc: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] Why bother removing features?

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Sat, 13 Jun 2009 12:51:24 -0700

On Jun 13, 2009, at 12:02 PM, Charles Lindsey wrote:

> On Sat, 13 Jun 2009 01:06:59 +0100, Steve Atkins <[email-masked] 
> > wrote:
>
> That is not so. All verifiers have to do is to check whether the  
> signature is good, and report accordingly to the Assessor. That  
> should include pointing out whether the signature matches the From,  
> and also indicating exactly which headers were signed, and reporting  
> on any tags seen. For that purposes it is entirely unnecessary to  
> understand what most of the tags are supposed to do. Just enough to  
> identify how it was signed and whether it was valid.

You might wish it were the case (and I do too, somewhat), but it just  
isn't so.

As a concrete example, if you have a public key containing the string  
"g=hatstand" and a signature that does not contain the string  
"hatstand" then any DKIM verifier must return that the message is  
unsigned, by the definition of a DKIM verifier - something that  
follows the explicit rules of section 6.1 of RFC 4871 (plus the  
implicit rules from other sections[1]).

It cannot do that if it ignores the "g=" or the "i=" flag.

It's easy to construct equivalent proofs for pretty much everything  
else (anything other than the PK n= flag, I think).

>
> And as for assessors, they can take as much or a little notice of  
> unusual tags as they see fit. There will care about some tags, and  
> simply ignore the ones they don't understand (this in spite of the  
> fact that understanding the more unusual tags may enable their  
> assessments to be more accurate). But it will take years of  
> experience for the assessment community to discover which tags they  
> need to take note of. A Best Practice will arise over time, but even  
> that may have to change as the Bad Guys find ever more ingenious  
> ways to get around the system.
>>
>> whether we do or not, though. ...
>
> No, that is just my point. They can probably ignore most of the  
> unusual ones, just so long as they include them in their hashes when  
> verifying.

A piece of software that ignores any feature that can affect whether a  
signature is valid or not is not a DKIM verifier, and will give the  
wrong answer in some cases. That might be acceptable to some users  
(including me, in some cases) but is not a DKIM verifier as designed  
by spec.

I think your argument boils down to "we don't need to change the spec,  
because everyone implementing it can ignore the bits they don't like".  
Apart from anything else, that seems as though it would lead to an  
awful lot of interoperability failures if some "DKIM verifiers"  
consider a message signed while some consider it unsigned.

Cheers,
   Steve

[1] 6.1 doesn't explain that the verifier must check the v= tag, for  
instance
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 15 Jun 2009 11:22:56 -0700

On Jun 13, 2009, at 4:51 AM, Dave CROCKER wrote:
> There is an infinite array of features that we may have need for in  
> the future.   So that's not an encouraging line of argument for  
> retaining any particular feature.

During early DKIM development about three years ago, I argued against  
adoption of user restricted DKIM keys.  Several individuals with a  
security background dismissed the concern by stating that a key MUST  
allow user restrictions as an essential feature, especially for remote  
signing.  My concern at that time was how this feature might be  
abused, such as those at Yahoo! suggesting they could publishing  
millions of individual's DKIM keys in DNS.  No doubt they could.

> Features carry costs.

Modifying DKIM also carries a cost.  The time to argue against these  
features has passed.

> Perhaps you missed my earlier note, which touches on the significant  
> costs of retaining unused features:

The definitions of unused features seem constrained to a subset of  
providers.

When influential providers want to develop different signing  
mechanisms, there is nothing preventing them.  In order to minimize  
the complexities in describing what a valid DKIM signature means, not  
changing how a valid DKIM signature is defined better preserves both  
the security and the clarity of DKIM signatures.  Changing DKIM's  
definition two years after its introduction opens more security issues  
than are resolved.

Perhaps some providers are upset that some DKIM features allow  
original messages to be isolated from injected ads, for example.   As  
it happens, some of these ads have caused security breaches due to  
various cross-site scripting and iFRAME related issues.  It seems the  
features being declared "unused" also enable the isolation of injected  
ads.  Often such injected content damages HTML page presentation when  
carried as an email  message.  Isolation of this information can  
ensure page annotations better preserve the intended presentation,   
and ensure the source of injected information is not confused with  
that of the sender.

-Doug

---

From: hector <[email-masked]>
Date: Mon, 15 Jun 2009 21:30:24 -0400

Douglas Otis wrote:
> original messages to be isolated from injected ads, for example. As it 
> happens, some of these ads have caused security breaches due to 
> carried as an email message. Isolation of this information can ensure 
> page annotations better preserve the intended presentation, and ensure 
> the source of injected information is not confused with that of the 
> sender.

DKIM should be renamed to SKIM - (Last) Sender Key Identified Mail.  It 
begins to make  sense then, since original authored domain mail have 
little control over it.

--

.

---

From: Jon Callas <[email-masked]>
Date: Tue, 16 Jun 2009 15:16:39 -0700

Let me reply with a "Yes, but."

It's far more likely that an unused feature will remain fallow than  
anything else. The interoperability issues you mention are real, but  
the usual effect is that the unused feature remains unused, not that  
it breaks things.

Nonetheless, you and I are of different styles on that issue, and I  
always see your point even when I disagree.

So let me say that I basically agree, I would only repeat what I'd  
said before that the burden of proof lies on those who would define a  
feature to be unused.

That burden of proof is usually not hard. If it's genuinely unused,  
one only has to listen for silence.

It gets more difficult when someone *plans* to use a feature. More  
than that when there's a debate about how useful a feature a feature is.

The debate we're having about h= and k= falls into that latter  
category. There is no technical reason to keep them. However, there's  
a feel-good aspect to them. The explanation of why there's no  
cryptographic need for them is complex. I've made it, Barry's made it,  
and yet there are people who want it.

In properly-running code, there's utterly no reason for either.  
However, some people don't feel good about it, and they have a point,  
albeit one I'm making better than they are.

Cryptographically, the cross-key-type error that they prevent are  
effectively impossible. (And if they're *actually* possible, then  
there are many scarier problems than a DKIM problem.) However, they  
enable a sufficiently clever programmer to have an extra level of  
safeguard against a software error that could cause a catastrophic  
failure of the *system*, not the cryptography.

While this is indeed unlikely, what's wrong with having an extra  
safeguard that makes people feel better about DKIM as a protocol?  
That's why I'm saying, "yes, but."

There are plenty of ways to answer these questions, but I still think  
that we still end up with a principle that the more controversial a  
feature is, the more it should stay. I'm all for cutting the things we  
decide in some rough consensus were better ideas two years ago than  
they are now. I'm just saying that the presence of discussion is a  
reason to just leave it. The controversy will end up with either the  
feature being used, or the lack of use becoming manifest.

	Jon