Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

["william(at)elan.net" <william at elan.net>]

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.net

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf