Steve,
While I very much appreciate the background, I think the
fundamental point I was trying to make remains unchanged and
part of your response further muddies the waters.
Russ's note suggests DNS-enabled clients. There is a serious
shortage of those clients for what I believe is still the
most-used operating system platform among IETF participants.
Your note seems to suggest concentrating on caching servers and
full-service resolvers. I think there are differences in how
various of us have done and interpreted the risk analysis but,
from what I've seen, well-known caching servers (such as ISP
ones) are the most likely targets of attacks. If they are, then
having DNSSEC verification only to those servers, with client
machines trusting the nearby caching servers without DNSSEC
protection, provides very little protection at all. Put
differently, if we cannot extend DNSSEC protection and
verification to the desktop, DNSSEC provides very little
marginal security advantage.
As several people have pointed out, effective use of DNSSEC to
the desktop requires sufficient work on APIs and UIs that an
application, or the user, can distinguish between "signed and
validated", "signed but does not validate", and "unsigned". As
long as verification is performed on the desktop machine (or on
a completely trusted, protected, and user-controlled local-LAN
caching server), it is reasonable for us to take the position
that those interfaces are a problem outside the IETF's scope.
But, as soon as we shift the verification problem to an external
caching server --whether an IETF one or one belonging to an
ISP-- and even if those are trusted, then one needs, not just
APIs but actual pieces of protocol to communicate that
information in an appropriate way. Without such pieces of
protocol, we put the DNS into the middle of the very worst of
the middlebox problem, with servers not under the user's control
making decisions about whether or not particular strings are
resolved or reported to the user machine as non-existent. I
have not been following the DNSSEC protocol work closely enough
to be sure, but my impression is that such protocol work has not
even been started, much less concluded and standardized.
With regard to the transparency of all of this to client
machines that don't do their own validation, it rather reminds
me of the distinction made in the stages of drug testing between
"safe" and "effective". Running DNSSEC-capable caching servers
--whether the ietf.org zone is signed or not-- should be
transparent to non-DNSSEC-aware clients unless there has been a
really major failure in protocol design or implementation.
That would demonstrate "safe", but not "effective". Perhaps
that is worthwhile, but I think it is a modest goal indeed and
one that has been accomplished many times already. To
demonstrate "effective", one not only needs signed zones (and,
IMO, zones signed from the root down, not locally-configured
look-aside arrangements which could prove something rather
different), but also needs enough carefully-seeded failure cases
to demonstrate actual protection of client machines from invalid
or hostile DNS records.
If one were to depend on look-aside mechanisms, then an
experiment to demonstrate effectiveness (and even some aspects
of safety) would need to test interoperability among look-aside
databases, different sequences of testing such databases, etc.
Any of those things would require very serious experimental
design. Some would require protocol or other work. For
example, if some zones are signed via one look-aside database,
others via another, and a few with the relevant keys stored in
several of them, do we need search rules for look-aside
databases and are we confident that the databases themselves,
and the paths to and from them, can be validated or are they
just another potential attack vector?
If all we have in front of us is a general proposal to turn
DNSSEC on during the plenary, plus or minus your note, I think
we might have the potential for a demonstration of "safe", but,
unlike, e.g., the IPv6 experiment, we are no where near showing
"effective". I'd really like to see a plan that brings us a
lot closer to "effective" and preferably one that more strongly
identifies some of the loose ends that this discussion has
brought out and is used as the basis of initiating IETF work to
get those loose ends tied up.
john
--On Thursday, 27 November, 2008 15:52 -0500 Steve Crocker
<steve(_at_)shinkuro(_dot_)com> wrote:
[As entertainment for the audience, I am sure everyone will
enjoy seeing my brother and I take opposite sides in this
discussion. Enjoy ;) ]
I too have been watching this thread but from the vantage of
having been deeply involved in DNSSEC deployment and, more
specifically, as one of the people urging deploying DNSSEC at
the IETF meetings. This thread began with Russ Housley
sending a brief message yesterday:
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf