Cullen,
This is why I still have some faith in the IETF process, common sense
engineering generally prevails or highlights the problem areas. Thanks.
My apology if the following inline comments goes beyond what you seek,
but I believe it summarizes an Implementor's engineering viewpoint for
the key reasons why a) 3-4 years of working on DKIM, have decided not to
implement it yet, and b) why we have these confusing issues and how
things evolved. I sincerely hope you would take a moment of your time
to read my comments.
Cullen Jennings wrote:
First thanks to the WG for trying to address the problem I had raised.
I had assumed nothing would be done to try and correct so I just put
abstain as clearly some people felt the document was worth publishing
but as we are trying to fix or clarify this, let me be more explicit.
My focus is mostly on what this errata means to implementations in the
field. That would be implementations of both DKIM the narrow signing
protocol and implementations that use the information DKIM provides. I
think the document should be clear on
1) what is the interoperability problem. Can someone succinctly
summarize this? When I read the document, I get that there is a
problem but it less clear what it is or why some implementation would
end up doing something that did not work with other implementations.
DKIM's purpose has been lost with the continued out of scope undefined
reputation modeling. A concern raised over and over again, Assessment |
Reputation - wink wink, same thing when it come to coding it. Word
smithing does not solve implementation issues.
When policy (SSP, not ADSP) was a major part of this project, there was
a defined purpose on DKIM handling.
In short, DKIM has a major problem with fault handling because the
focus here is on filtering NON-ANONYMOUS white listing as opposed to
filtering ANONYMOUS faults. I called this the "Looking for the Golden
Needle in the Haystack" problem when in steady state, receivers will be
bombarded with a high volumes of unhandled faults only focusing on
non-anonymous valid signatures.
For example, cisco.com exposes an exclusive policy signing policy, (only
cisco.com signs its mail), a DKIM verifier now has 0% false positive
fault handling based on the author domain acceptable expectations. If
cisco.com doesn't publish a policy, verifiers are lost when it comes to
faults. The only thing available is depending on some form on
reputation assessment. I had called this problem the "Battery Required"
syndrome. Now receiver systems MUST have some sort of reputation lookup
either local or by 3rd party service, the latter being the key conflict
of interest focus by the key cogs of this group.
This is the principle reason as an potential implementor after 3-4 years
participation in the WG, in house development, testing, simulations, we
see no payoff under the current model and thus have little incentive to
add DKIM into our product. I have a problem exposing my customers to a
protocol that requires "Batteries" in order to work.
2) what needs to be changed in implementations to fix this? Again, can
anyone succinctly summarize this. I do not think an implementor that
did not follow the list could easily read the current draft and figure
out if there code was OK or not and what changes where needed to their
code to make it OK
You hit the problem in your inline comments. The design issue is overall:
d= relates to 1st party signatures
i= relates to some 3rd party involvement.
I venture that when DKIM signing was added to the mipassoc.org list
server and it began to blindly sign mail as a 3rd party, the issue of
whose policy do you lookup became obvious; the original domain author
(From:) or the signer d=? Since i= reflects the From: address, there
was a potential policy design conflict.
This is when Dave began, what I felt was one of the oddest situations I
have every seen in my engineering life, to introduce new acronyms and
strange terminologies in what appears some vain attempt to change the
"mindset" and meaning of what he was trying to model DKIM on, a non
policy based framework using reputations, oops "assessors" to evaluation
the handling of DKIM mail.
The thing is, this was resolved with the broader SSP draft. But that
was ambushed by what some believe was a poison pill with a trimmed down
ADSP. While its against my personal ethics to share private
conversations, I think it is important to note that even Eric Allman
thought ADSP was done to kill policy (using a non-consensus WG
outcome). ADSP does not resolve the problem for list servers and its
only deeming value was its single policy - an exclusive signing
DISCARDABLE policy. ADSP does not address other real world high volume
situations.
Overall, from an engineering standpoint, the focus was lost:
DKIM did not adequately address the handling of 1 to 1
communications because the intent to make it work with List Servers,
a 1 to Many communications model. This requires an ignorance of
author domain policies.
The now expired I-D proposal I wrote back in July 2006:
DKIM Signature Authorization Protocol (DSAP)
http://tools.ietf.org/html/draft-santos-dkim-dsap-00
was done as a SSP derivative to cover the security concerns I had with
DKIM not addressing the obvious fault handling based on simple common
sense FAULT policies:
- Mail with this domain was not expected (domain not used for email)
- No signature is expected (I never sign)
- No 3rd party signatures was expected
- Only 1st party (Author Domain) Signature was expected
I even had a PPS presentation ready in anticipation of attending the
IETF DKIM meetings:
http://www.winserver.com/public/ssp/dsap-00.pdf
But the real incentive for writing DSAP was because of the "Writing on
the Wall" WG atmosphere to eliminate SSP not on technical terms but
because of rising conflict of interest by those who wanted a
reputation-based DKIM business models. Not opposed to it, I'm a
business man myself, but I felt it was not good as a basis framework for
the general network of potential DKIM implementors - signers,
verifiers or both. When I was told by the chairs not to worry 'SSP will
happen one way or another," I agreed to support SSP and not
follow through with DSAP. This helped the chairs and WG with less
competing policy drafts which I am 100% all for. But if ADSP was
foreseen, I would not have never dropped DSAP. The irony? Even the ADSP
author doesn't believe in his own work and has proposed to move it first
eliminate it and then move to experimental status.
Thanks
--
Hector Santos, CTO
Santronics Software, Inc
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html