-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Monday, April 07, 2008 2:19 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html