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