[ietf-dkim] Delegating responsibility: a make vs. buy
Bill.Oxley at cox.com
Bill.Oxley at cox.com
Fri Aug 25 12:38:16 PDT 2006
I must be missing much of this argument.
Dkim.bar.com=ISP.com does all of my signing
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.
Cox Communications, Inc.
bill.oxley at cox.com
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
>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.
NOTE WELL: This list operates according to
More information about the ietf-dkim