On Fri, 23 Dec 2005, Nathaniel Borenstein wrote:
I generally try to stay out of discussions when everything has already been
said a thousand times, but this one is too important to ignore, and I fear
that people are arguing over red herrings rather than speaking plainly about
the underlying issue. So in what follows I will try to give a reasonably
simple explanation of why a bunch of long-term IETF guys decided to form a
private group to develop DKIM:
I think simple explanation is the one you can fit in one sentence, this
wasn't it...
On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote:
Yes, the DKIM group clearly purposely bypassed discussions as part of
MASS (i.e. ietf open forum) in order to do it in private and leave only
one authorization method
This is completely backwards, the precise opposite of why a few of us
decided to start a closed, private group to define what became DKIM. Far
from trying to "leave only one authorization method," the DKIM effort is an
attempt to show, by example, how an arbitrary number of such methods might
eventually be elaborated and standardized. It is an attempt to define one
method first, as a step towards defining as many of them as
possible/necessary rather than arguing endlessly over which is best. For
most of us, support for DKIM does NOT imply opposition to any other
proposals related to controlling spam and related ills. A lot of us who
have worked on DKIM were previously active in trying to bridge the gap
between SPF and Sender-ID, and despite the disappointments we'd still like
to see that effort succeed, as well as quite a few other anti-malware ideas
and technologies.
Talk about "red herring". I specifically meant authorization method
used with email automated (mailserver-added) signatures and you change
the subject be different kinds of email "authorization" systems. I'm
in fact all for different types of systems and supported wider view
of the problem and use of multiple tools (if they don't interfere
with each other), but not standardization of closed designs.
So what is true is that I did not get it wrong. MASS originally was
discussing several authorization methods: public keys in DNS,
fingerprints in DNS (and in special HTTP fingerprint server),
X509 certificates located on HTTP server and X509 certificate servers.
In DKIM however there is left only public key in dns (and talking about
other methods would be excluded by means of the working group charter)
and I do not believe this issue was ever properly decided on and my
argument is that there should be more authorization methods being
available (in initial release, otherwise they'd never really get deployed)
because public keys retrieval from domain root is too limiting and can
not for example fit all scenarios well; plus I think this "chosen" method
is in fact the worst one [based on possible impact to infrastructure]
of those available (although it does have large vendor supporting it
and only it as usual...)
For reference as to how it all occurred you might want to go back one
year and glance at
http://web.archive.org/web/20050204075618/mipassoc.org/mass/crocker-features-iim-dkeys-09dc.htm
and that might make you wonder what is ESTG (care to guess about what
this acronym stands for...) which has its own meetings and mail list -
http://mipassoc.org/mailman/listinfo/estg-general
it was mentioned on ietf too:
http://www1.ietf.org/mail-archive/web/ietf/current/msg39474.html
BTW - even more interesting message was recently leaked out of it:
http://www.mhonarc.org/archive/html/ietf-dkim/2005-12/msg00115.html
I'm against doing standardization in limited (and especially private
and closed) forums and to me this is what it looks like MASS turned
out to be (and I really don't care if this had few "long-term IETF"
folks involved or not). When some SPF folks wanted to do their own
standardization group I had some strong comments on their effort too.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf