At Mon, 21 Oct 2002 21:50:49 +0300 (EEST), Pekka Savola wrote:
>
> Can you elaborate, which discussion? I did a few searches in the mail
> archive but didn't find anything relevant.
Postings dating back to March of this year, including the following.
--- Begin Message ---
At Tue, 14 May 2002 20:19:32 -0400, Steve Bellovin wrote:
>
> >So how can we understand the threat model for DNS discovery?
> >
> That takes work... A good starting point would be Derek Atkins' and
> Rob Austein's DNS threat analysis document
> (draft-ietf-dnsext-dns-threats-01.txt) I haven't had a chance to
> read it carefully in this context. Rob, I know you're on this
> list...
I replied to this over a week ago, but my reply never made it to the
list (no doubt my message had the wrong RFC822 From: header).
At any rate, as best as I can recall what I said last week, and with
the understanding that I'm not claiming to understand all the issues
here (far from it), this is just some preliminary thinking out loud
(ok, on phospher):
There's a fundamental question of whether one trusts the local network
or not. I don't. Some do. Threat models for any discovery protocol
depend heavily on where one stands on this point.
Recursive mode (usually stub) resolvers without DNSSEC are walking
targets: they're just throwing themselves on the mercy of some
recursive mode name server and don't have much grounds for any kind of
opinion on the results they get back. DNS Discovery probably doesn't
change this model very much.
Iterative mode resolvers without DNSSEC are also at risk (see the
dns-threats draft), but the scenario is a bit different. In theory,
an iterative mode resolver can try somewhat harder to get a valid
answer, but without end-to-end data integrity protection the resolver
is still in a pretty weak position. The main difference here as far
as DNS Discovery is concered, though, is the bootstrap configuration
data needed by an iterative mode resolver is (in practice) disjoint
from the bootstrap configuration data needed by a recursive mode
resolver. That is: while, in theory, an iterative mode resolver's
"SBELT" (see RFC 1034) can be primed with some arbitrary list of name
servers that the resolver turns to when it has no better idea of where
to send a query, in practice SBELT is almost always set (via out of
band means) to the IP addresses of the servers for the root zone.
With DNSSEC, the picture is a bit different. DNSSEC provides an
end-to-end data integrity check, so that resolvers are no longer just
trusting name servers to return the right answer. But it's a bit more
complex than that, with several subcases.
A recursive mode (usually stub) resolver that uses the lame-oid "ask
the recursive mode name server to do all that annoying DNSSEC junk"
misfeature is not a lot better off than a recursive mode resolver
without DNSSEC. Essential, there are now two separate trust
mechanisms: the DNSSEC end-to-end data integrity check (which in this
case does not go end-to-end), and whatever mechanism the resolver uses
when it's talking to its chosen recusive mode name servers. The
current least-bad mechanism for the latter mechanism is TSIG, but
there's a nontrivial key distribution problem there. So either the
recursive mode resolver needs some out-of-band knowledge of some kind
of keying material that it can use to secure its conversations with
its chosen recursive mode name servers, or the DNS discovery protocol
has to supply the necessary keying material.
As noted in the dns-threats draft, simply establishing a "secure"
channel between the recursive mode resolver and the recursive mode
name server isn't sufficient, because "secure" communication to a
server that the resolver has no reason to trust is not particularly
useful. Also note that hiding the DNS Discovery process from the
resolver (which, in my opinion, is what the well-known-address
proposal does) may make the (already bad) trust model here even worse:
if the resolver doesn't know which name server is using a particular
well-known IP address at the moment, it may have a harder time
figuring out which key it use to talk to that name server.
An iterative mode resolver is in fairly decent shape with DNSSEC,
since it can perform the end-to-end integrity checks itself and thus
no longer needs to trust any name server blindly, but there's a key
distribution problem for this case too: the key for the root zone.
Once again, either the resolver has to know that a priori, or the
resolver needs some trustworthy way of acquiring that knowledge.
There's a third weird case that has not yet received a lot of
discussion: a recursive mode resolver that does its own validation of
DNSSEC signatures. The basic idea here is that the DNSSEC integrity
check is an end-to-end mechanism, while the mechanism by which DNS
data is retrieved is essentially hop-by-hop (due to DNS caching). So
it seems perfectly reasonable (to me, anyway) that an implementation
might want to offload the process of fetching the data but still want
to verify the integrity of the data. This case hasn't gotten a lot of
attention to date, so the precise details of how one would go about
this haven't been nailed down. I think it's possible (if somewhat
annoying) to do this with DNSSEC as currently specified, which is why
I haven't made a big issue out of it.
For any case in which the resolver might be checking DNSSEC
signatures, there's also a time discovery problem, because DNSSEC
signature verification includes checking the expiration time. While
it's probably safe to assume that any toaster capable of implementing
DNS is capable of measuring elapsed time while the toaster is running,
it's not safe to assume that every toasters has a clock that ticks
while the toaster is turned off. So DNSSEC signature verification
also adds a clock setting problem, which has its own set of trust
issues. (S)NTP (with its authentication mechanism enabled) seems
sufficient for this, but adds another key distribution problem.
So: in all of the DNSSEC-using cases, there are key distribution
problems of one kind or another. Big surprise. So part of the
discovery question is to what extent one can or should use the
discovery protocol to deal with the key distribution swamp.
As far as I know, the discovery via well-known addresses proposal does
not yet have any mechanism for dealing with this. It's not obvious to
me where one would hang such a mechanism, but maybe I'm missing
something.
The "stateless DHCPv6" approach could, in theory, use DHCPv6's
authentication mechanism, but as specified that mechanism doesn't look
like an appropriate solution to this problem either. Then again, it
might be possible to reuse the DHCPv6 authentication framework with
different algorithms; that is, in this case, I can see where one might
hang a mechanism, if we can come up with an appropriate mechanism.
Ultimately, however, there's still the basic problem of to what extent
the node trusts its local network, and what basis (eg, out-of-band
keying) the node has for trusting any server it discovers if it
doesn't trust the local network.
--Rob
--- End Message ---
