I must be missing much of this argument.
Dkim.bar.com=ISP.com does all of my signing
Dkim.isp.com=publickey_yadayada
That is manageable and not inventing a new technology. I think we need
to avoid not only Touring Complete syndrome but also Tourettes as well.
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Friday, August 25, 2006 3:17 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision
My point is that without the DSD mechanism, key delegation is arguably
much more likely to be used. And if true, that means we have to do more
work analysing key management. With DSD, key delegation is arguably
much less likely to be used, or at least can be more easily avoided, in
which case analysis of key management is less of an issue for us.
I can see how the analysis would be different, but it's hard to see
why it would be less complex.
With DNS delegation, the name space is a tree, and we understand the
security properties of tree delegation pretty well, warts and all.
With DSD, we now overlay a graph with unknown security properties onto
that tree. I'd hope we have enough self-discipline to keep it a
two-level graph rather than a Turing complete rats' nest a la SPF, but
recent discussion here is not encouraging. Even as is I am pretty
sure we have not yet explored all of the grotty things one could do
with existing DNS features and one level of indirection in SSP. We've
already seen one subtle security bug in a single indirection scheme
that seems to have no solution short of doing severe violence to
dkim-base, and that surely will not be the last.
To me, it just seems nuts to invent a new mechanism with unknown
properties that has not yet been implemented anywhere merely to make
an end run around a few providers who don't currently offer the well
understood delegation scheme that is used for everything else.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html