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