ietf-dkim
[Top] [All Lists]

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

2008-04-09 12:19:56


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Wednesday, April 09, 2008 2:27 PM
To: Eric Allman
Cc: ietf-dkim(_at_)mipassoc(_dot_)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



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>