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

[Jim Fenton]

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