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

[MH Michael Hammer (5304)]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Dave Crocker
> Sent: Wednesday, April 09, 2008 2:27 PM
> To: Eric Allman
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs.
> protecting a domain tree
> 
> 
> 
> 
> Eric,
> 
> Actually from your note, it looks to me that you understand just fine.
> 
> It looks as if the question is covering a single-name vs. a sub-tree.
> Your note
> mostly takes sub-tree as an implicit given, but then states it
explicitly
> at the
> end.
> 
> The attack that you describe requires using some name other than the
one
> that is
> listed.  The single, specific name that is listed is, indeed,
"protected".
> 
> 
> > If that's what you mean when you say "that presumes the goal of
> > protecting an entire sub-tree" then I'm all for protecting the
entire
> > sub-tree.  Anything less looks to me like it severely weakens the
entire
> > point of ADSP.
> 
> (Aside:  Folks keep correcting my own use of the word "protect" for
DKIM
> or ADSP
> and given the delicate balancing act that ADSP must walk, I think
their
> concern
> is quite reasonable.  So I'm trying to switch over to say "cover"...)
> 
> You echo the word "goal".  That certainly seems like the right
starting
> point.
> 
> Does the working group assert the goal of covering entire sub-trees?
> 
> Note that this isn't in the working group charter, the requirements
> statement,
> or even explicitly stated in the specification.
> 
> That does not make the goal inappropriate, but it does mean that it
needs
> to be
> stated and confirmed explicitly.  (And certainly the specification
needs
> to
> state this explicitly and clearly.)
> 
> But frankly that's the easy part.  Because we then we have the small
> question of
> what are the technical requirements and details, for covering a
sub-tree
> adequately, within the DNS, when using an underscore sub-naming
scheme?
> 
> Given that the DNS is not designed to permit this conveniently and, in
> fact,
> does not seem to me to be able to do it at all, we certainly need a
> complete and
> coherent technical description of how ADSP accomplishes complete
coverage
> of a
> sub-tree.
> 
> This would describe the approach being taken for covering a sub-tree,
and
> the
> component mechanisms being used to achieve it -- Step 2 is but one of
> those
> components. It would also demonstrate what kind of attacks it protects
> against.
> 
> I am not aware of any previous technology providing such sub-tree
> functionality,
> and so this ought to be subject to careful review by the DNS and
Security
> folks.
>   At that, I fear it will nonetheless warrant a status of
"experimental".
> 
> So in terms of a "goal" I'm probably in agreement that it would be
dandy
> to do.
>    But I think that my desiring that goal is pretty much irrelevant.
> 
> The problem is that I believe there is no technical means of covering
a
> subtree
> completely, except by case-analysis, which isn't covering a tree at
all.
> 
> I believe the Step 2 query only makes sense for ADSP in the context of
> covering
> an entire sub-tree, but that ADSP does not describe the larger
framework
> into
> which Step 2 fits, for accomplishing that goal.
> 

OK, you all tricked me into looking at section 4.2 again. My first
question is whether we are working from
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-03.txt or is
there something later floating around?

The reason I ask is that if ssp-03 is it then I think there is a minor
cleanup for step 2. It says " This query MAY be done in parallel with
the query made in step 2." I think it really means to say " This query
MAY be done in parallel with the query made in step 1." 

In response to the question Dave asks, I like the idea of providing the
option of protecting an entire (sub)tree within in a domain. My question
to the gurus is whether there is a clean way to identify "main" domains
below a TLD. For the generics this would appear to be straight forward.
For country TLDs I'm not so sure. Some country TLDs might always require
a .co.TLD or .edu.tld (or something similar). Not only is there
inconsistency across such TLDs, there may be inconsistency over time as
far as requirements within a TLD.

What started me thinking along this line was allowing a base domain (if
you will) to make an assertion that ALL subdomains only send signed mail
(or never sign mail or ?)

Just a thought.....

Mike