ietf-dkim
[Top] [All Lists]

RE: WG Review: Domain Keys Identified Mail (dkim)

2005-12-23 18:47:39
Perhaps we could provide a material proof of what John is asking for if we 
published the other two schemes that are essentially identical to DKIM. I can 
certainly try to get the VeriSign spec released.

I think that if four independent high-level engineering teams come up with 
essentially the same idea at the same time then that is a pretty good reason to 
think that the approach is well founded and likely to be stable.

If people have a different view on how to solve the same problem let them start 
their own WG or submit an individual ID. 

What we have here is not just a coalition of companies it is a coalition of 
many of the best known security specialists who work on protocol design. If we 
ever have the Internet crimewave under control some of us might be considered 
experts.


This is not about 'pre-picking one solution' as some claim. It is about 
recognizing the fact that four independent groups that came up with the same 
idea have agreed to pool their essentially similar ideas and bring a joint 
proposal to the IETF supported by an even larger group.

I do not think it is reasonable for the answer to that proposition to be 'go 
spend 12 months defending your idea against everyone with an opinion and a 
keyboard'.


-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Michael Thomas
Sent: Thu 22/12/2005 8:18 PM
To: John C Klensin
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org; 
ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
 
John C Klensin wrote:
In addition, there is, I think, one other approach that might be
appropriate, but only in very limited circumstances.  That
approach applies where there is a well-thought-out approach with
design team consensus, evidence of implementation, and no
clearly-identified technical concerns.    Then, and only then, I
think that an approach of "the WG gets to challenge the base
spec and assumptions, but to change them only if there is good
reason and consensus to do so" is plausible with a standards
track target.  I think that XMPP, and the XMPP language,
probably is an instance of that case.

Other than claims and counterclaims, I've seen little that would
permit the IETF community to form a consensus about exactly what
stage the DKIM work (and implementation, deployment, and
demonstrate that it accomplishes whatever is being claimed) is
really at, a consensus that seems to me to be necessary to
determine whether it should be chartered as a WG if  there are
going to be any restrictions at all on what that WG can
consider.  That strikes me as sad since, beyond philosophical
debates, it seems to me to be the key issue.

I obviously think it's closer to #4 than anything else. Note
I wasn't weighing in about whether this piece of word-smithy
vs that was better or not, just my concern that the lack of
negotiation/feedback make the backward compatibility problem
far more nettlesome than other protocols that have that
luxury. There is a substantial risk that a bunch of gratuitous
thrashing around -- or worse a greenfield makeover ala MEGACO --
will cause this effort to crater. Given MARID, I don't think
we get many chances and that this is really a situation where
the best is the enemy of the good.

As such, I think it's reasonable for the charter to limit the
scope of changes to those that will really tighten up the mature
parts of the specs instead of a, IMO, futile -- and destructive --
trip back to first principles. False dichotomy? Maybe, but not
out of the question if there is no limit at all, and that's
pretty bothersome for those of us who advocated taking this
to ietf and tried really hard to make this look like
something that would pass ietf muster.

Finally, I understand that for many people there are larger
principles at stake about the nature of ietf, etc, etc. I can't
tell you how thrilled I am that we are the posterboy for _that_
argument.

                Mike

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf