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