[ietf-dkim] Delegating responsibility: a make vs. buy designdecision

[Bill.Oxley at cox.com]

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.oxley at cox.com 

-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of John Levine
Sent: Friday, August 25, 2006 3:17 PM
To: ietf-dkim at mipassoc.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