On Fri, Nov 28, 2008 at 10:09:16AM -0500, John C Klensin wrote:
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.
This doesn't actually follow, because there could be another way to
validate the link between the end host and the validating recursive
resolver. For instance, we could use TSIG between a non-validating
stub resolver and a validating recursive resolver in order to ensure
that attacks between those two points aren't successful. If I know I
have the right node doing the validation for me, then attacks against
the ISP's validating recursive resolver require complete takeover of
that machine: by no means impossible, for sure, but a bigger deal than
just spoofing answers to a stub resolver.
That said, I don't want to make light of the end-point problem, since
TSIG between a stub and a recursor isn't a trivial problem today
either. Moreover, since end nodes in many environments get their
recursor's address(es) via DHCP, and since that path is pretty easy to
compromise, the whole edifice rests on a sandy foundation.
Nevertheless, I just want to be clear that having every end node in
the world doing RFC 4035-and-friends validation is not the only path
to useful DNSSEC.
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".
Why? It seems to me that acceptable definitions of "works" and
"doesn't work" in a security-aware context could include "validated or
insecure delegation" and "bogus delegation" respectively. In my
opinion, any plans that involve users making sensible security
trade-offs due to validation failures will get us right back where we
are with self-signed or expired (or both) certificates for https. It
seems a perfectly good idea to me that "bogus" means exactly the same
thing as "site off the air".
As a DNS geek, I'd _prefer_ more-intelligent end points with respect
to the DNS. But I don't buy the argument that they're a necessary
condition for DNSSEC deployment.
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.
You have exactly two options: allow the recursive server to make the
decisions you seem to dislike -- and I think people who like that
approach think it's a feature, not a bug -- or else to do validation
out at the end nodes. The end node gets a bit to tell upstream
validators that it is going to do all validation itself, and those
upstream systems are required to pass along all the data necessary for
such validation. So it's still possible to do everything at the end
node.
This is quite independent of the question of whether applications have
the ability to understand the results from the validator. I agree
that OS APIs seem to be missing. I'm not sure that's something the
IETF ought to be solving, but I'd happily entertain arguments either way.
several of them, do we need search rules for look-aside
databases
My personal reading of the current specifications is that, if you have
at least one path to validation, then validation is supposed to work.
So search rules ought not to be needed. What the implementations
actually do is currently at variance with my interpretation, however.
A
--
Andrew Sullivan
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf