ietf-dkim
[Top] [All Lists]

[ietf-dkim] Why bother removing features?

2009-06-11 06:33:24
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