Eric Allman wrote:
Dave, I'm not understanding how the algorithm can work if you omit step
2 from section 4.2.2.
Suppose that example.com wants to assert to the world that it signs all
messages. It will create an ADSP record for example.com with the
appropriate assertion. Without step 2, all an attacker has to do is to
craft a message purported to be from
"attacker(_at_)some(_dot_)thing(_dot_)example(_dot_)com"
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html