[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

[Siegel, Ellen]

> -----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
discussion...
> 
> Dave Crocker wrote:
> > Folks,
> >
> > This issue encompasses some others, but I believe it is more basic
and
> therefore
> > 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
doesn't
> 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,
but
> 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
about
> 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
domain. 

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
discussing subtrees. 

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
> attribute
> > of the domain name it is under, rather than defining a true "name".
> >
> >      What this leaves us with is attempting to invent mechanisms
that
> 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
as
> hostnames but are legal for some other purposes.
> 
> DNS wildcards are indeed useless in the face of name prefixes, which
is
> 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.
Some
> is for
> > expanded semantics.
> >
> >      It's not clear that the specification is clear about this
> distinction.
> >
> >      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
> information
> > from the absence of publisher action.  Let me explain:
> >
> >      I believe the desire with checking the A record is similar to
the
> idea
> > 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
> signature.
> > It does that by defining something else that must be present.  If
the
> ADSP
> > 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
try
> 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
> semantics
> > have literally nothing (directly) to do with ADSP.
> >
> 
> ADSP is not checking the A record, as others have pointed out.
> 
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html