Jim Fenton wrote:
Dave Crocker wrote:
I keep waiting for proponents of this 'feature' to solicit technical
review from independent DNS and security experts, for assessing the
likely benefit as balanced against the likely cost.
I have been soliciting technical review from the DNS folks, literally,
for years, on this and prior iterations. I recall quite clearly a
lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over
Excellent. So it will not be difficult to document that formal review so that
the rest of us can consider its careful documentation of the DNS community's
assessment of the peculiar mechanisms defined in the working group draft.
The point behind my probe for formal review was just that: formal review.
Casual, private conversations might be a precursor, but they are not
sufficient, particularly when seeking to modify the DNS's exact-match paradigm
for queries.
two years ago. I have been less concerned with independent security
review, since we are in that area and I expect that will happen with the
specification as a whole, not just this aspect of it.
Jim, waiting until we are done, to get buy-in from the rest of the security
community is singularly ill-advised project management. It maximizes risk and
minimizes benefit, particularly when there is very basic concern over the
efficacy of what is being proposed.
I realize that you are not the one with the concern, but you might have
noticed that there are others in the working group who do not share your
comfort?
The requirement to publish large numbers of ADSP records is a barrier
to its widespread adoption
That's a view I do not recall seeing phrased quite that way before.
It's nicely succinct and pragmatic. The only question is where is its
basis and, again, the broad support for the assessment that
substantiates it?
For example, John has provided some counter-arguments suggesting that
the actual, incremental effort to deal with a large number of
parallel, related domains -- for this particular RR -- is not all that
high, particularly in light of the core requirement for change to
...
I don't see an analysis for John's assertion either.
When seeking to add something to a specification, the burden of establishing
that it is necessary or, at least, beneficial, falls on those who are
proponents. Additions create costs. In the case of Internet standards, the
costs are large-scale and long-term. The costs need to be justified.
Let me anticipate a counter-argument that might be put forward: The feature
in question is already in the specification so the challenge is in
establishing that it must be removed. The problem with this view is that
there was never a clear consensus to add it. Really. I've asked for
documentation to the contrary and it has not been forthcoming.
broad coverage for domains. This can be addressed with tools, but
the requirement to add tooling to achieve good ADSP coverage is also
a deployment barrier.
As John noted, there is already a requirement for modifying tools, in
order to support ADSP.
Not DNS tools. The requirement to modify DNS tools to achieve broad
coverage would be an additional requirement.
I don't understand your response.
Similar concerns led the WG to the use of TXT records rather than a
new RR.
Not really. The infrastructure barrier to support of a new RR exists
with both those who create the record as well as those access it.
The barrier for ADSP is only with those who create the record. Very,
very different dynamic.
Agree that ADSP requires changes only on the publication side. I still
believe that this introduces a significant barrier.
Having to make any changes to DNS administration is a barrier. Right.
And your point is what, exactly?
The current point was not whether there was any barrier at all, but rather it
was about your attempt to equate the height of the barrier for a new RR with
that of a new use for an existing one (TXT). My response was that they are
massively different barriers.
There are a lot of DNS management tools out there that would need
to change in order to publish the necessary ADSP records, and this
would take considerable time.
They already need to change, to support one record (for one domain.)
How is there something fundamentally worse about having to support many?
The tools don't need to change; the additional TXT record for ADSP can
just be published independently using existing tools.
Jim, some DNS admin tools do not automatically permit that. They need to be
changed.
We have two approaches to this problem, one approach which requires more
effort on the part of ADSP publishers (either manual publication of
additional records or deployment of new DNS tools), and one approach
that requires more effort on the part of ADSP users, although that
effort is largely contained within the software implementing ADSP and
transparent to the deployer. Let's just treat this as an engineering
tradeoff.
Yes, let's. But let's do that in a discussion with substance, rather than a
wave of the hand, which is frankly what I think the above paragraph represents.
An engineering tradeoff decision needs an engineering costs/benefits discussion.
For the current case, the choice is between a possible burden on what is
probably a small number of administrators, versus a very real real-time
overhead burden on virtually every email exchange over the open Internet...
forever. Worse, the burden is not likely to have accompanying benefits.
I'm rather surprised this has become such an issue for you and John
since this same approach is used in draft-levine-asp-00, which John
edited and on which you collaborated.
Here, you move into a kind of process challenge, and even toss in some ad
hominem. Citing only John and me also nicely seeks to marginalize the concerns.
More importantly, you seem to have missed or forgotten a number of my own
postings that explain what is motivating the concerns.
So let's review some history about *technical* and *operational* concerns:
On 11 April, Dave Crocker wrote (to you privately):
Have you considered the relative costs (and benefits)?
who has to publish the extra records? for how many of these will that
be onerous?
who will do the extra queries? for how many queries will the extra
overhead be useful?
Did these not seem sufficiently basic or legitimate questions? They ought to
explain my own reason for pressing concerns about these extra DNS details.
How about my 9 April posting to the list:
Dave Crocker wrote:
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.
How about 2 March:
Dave Crocker wrote:
Put forward as an efficiency hack, to avoid having to make a number of
one-level-down DNS records, the mechanism has no claim towards affecting
security. Taken on its own, therefore, the question is whether the
mechanism as a) worth the effort on a normal implementation cost vs.
operational benefit basis, and b) worth the effort to run contrary to
established DNS practice and, now, IAB preferences.
Put forward as having any security characteristics, such as enforcing
the ASP security model, this DNS hack is likely to have quite a bit of
pushback, as you note.
I seem to recall other, earlier and similar postings, but these ought to
suffice, both to explain why the matter is being pressed and that pressing the
matter is being spontaneously generated.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html