[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
esiegel at constantcontact.com
Mon Apr 7 12:41:16 PDT 2008
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Jim Fenton
> Sent: Monday, April 07, 2008 2:19 PM
> To: dcrocker at bbiw.net
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs.
> protecting a domain tree
> Since the Chairs have ruled that this warrants yet further
> Dave Crocker wrote:
> > Folks,
> > This issue encompasses some others, but I believe it is more basic
> > informs the others and therefore needs to be resolved separately:
> > There is a basic difference between trying to protect a single
> domain name,
> > versus trying to protect an entire sub-tree.
> Two comments:
> (1) It's worth being careful about the word "protect"; the draft
> use it (except once, in a somewhat different context) and we should be
> careful about setting an expectation that publication of ADSP confers
> protection. There is benefit to the publisher that may be viewed as
> protection that comes from the use of ADSP information by verifiers,
> it is indirect and only to the extent that ADSP records are retrieved
> and used.
> (2) ADSP does not publish information about entire subtrees, only
> domains and labels within an immediate domain.
Jim, in your presentation to the ESPC you brought up the fact that one
reason to encourage sub-domains to publish 'unknown' ADSP records was so
that they wouldn't inadvertently inherit an ADSP record from a parent
As long as such inheritance is possible, i.e. that a subdomain can
automatically inherit from a parent domain, it must be true that we're
If we retain that capability, inadvertent or not, in the spec, I think
we need to call it out explicitly and discuss how to counter it.
However, I agree with Dave that it may be cleaner to just exclude the
possibility of inheritance rather than try to deal with the fallout.
> > 1. The DNS was not designed with sub-tree operators. The wildcard
> mechanism is
> > a very narrowly-defined capability and is useless in the face of
> > underscore-based naming, since the underscore node really defines an
> > of the domain name it is under, rather than defining a true "name".
> > What this leaves us with is attempting to invent mechanisms
> turn out
> > to do only a partial job, at best.
> Underscore-based names have no special standing within DNS (such as
> definition of attributes), other than the fact that they are illegal
> hostnames but are legal for some other purposes.
> DNS wildcards are indeed useless in the face of name prefixes, which
> why ADSP does not depend on nor use them. The mechanism described in
> the draft may be viewed as doing a "partial job" but we still need to
> consider whether what it does is useful. I believe it is.
> > 2. Some of the sub-tree effort is for administrative convenience.
> is for
> > expanded semantics.
> > It's not clear that the specification is clear about this
> > It is not clear that the specification is clear about the
> motivations that
> > make it mandatory to add sub-tree mechanisms to the specification.
> Again, I reject the premise that this a sub-tree mechanism.
> What are the "expanded semantics" to which you refer?
> > 3. At least one of the sub-tree mechanisms is attempting to glean
> > from the absence of publisher action. Let me explain:
> > I believe the desire with checking the A record is similar to
> > behind having ADSP in the first space.
> > That is:
> > a) DKIM is for declaring the presence of an accountable
> identity. If a
> > signature is present, you know something. If it is absent, you know
> nothing extra.
> > b) ADSP attempts to tell you something, in the absence of a
> > It does that by defining something else that must be present. If
> > record is present, you know something. If it is absent, you know
> nothing extra.
> > c) Checking for the presence of an A record is intended to
> tell you
> > something in the absence of an explicit action by the domain owner.
> That's it's
> > flaw: It is intuiting ADSP information from non-ADSP action.
> > While there is nothing wrong with checking the A record, it's
> > have literally nothing (directly) to do with ADSP.
> ADSP is not checking the A record, as others have pointed out.
> NOTE WELL: This list operates according to
More information about the ietf-dkim