[78957] in North American Network Operators' Group
Re: DNS cache poisoning attacks -- are they real?
daemon@ATHENA.MIT.EDU (Joe Abley)
Sat Mar 26 21:24:49 2005
In-Reply-To: <Pine.GSO.4.58.0503261947490.25244@clifden.donelan.com>
Cc: nanog@merit.edu
From: Joe Abley <jabley@isc.org>
Date: Sat, 26 Mar 2005 21:23:51 -0500
To: Sean Donelan <sean@donelan.com>
Errors-To: owner-nanog@merit.edu
On 26 Mar 2005, at 20:15, Sean Donelan wrote:
> Signatures don't create trust. A signature can only confirm an
> existing
> trust relationship. DNSSEC would have the same problem, where do you
> get
> the trustworthing signatures? By connecting to the same root you don't
> trust?
No, by using a known local trust anchor for the root and following the
chain of trust from there.
> As a practical matter, you can stop 99% of the problems with a lot less
> effort. Why has SSH been so successful, and DNSSEC stumbled so badly?
For most people SSH encrypts a session, and says nothing about the
identity of the remote host. Most people ignore the warnings about host
keys changing, and never check an ssh fingerprint with the remote host
before accepting it and caching it until next time.
DNSSEC doesn't attempt to encrypt the transport; it is all about the
authenticity of the data. So, they are doing different things.
SSH deployment requires no coordination between organisations really;
while there are public services deployed over SSH, I would be very
surprised if its main use is not intra-organisation. DNSSEC, on the
other hand, requires extensive standardisation and buy-in from a huge
number of different organisations before it is useful in a general
sense.
(You can use DNSSEC in a private, intra-organisational context, much as
you might use SSH, today.)
I'm not sure what 99% of DNS authenticity problems you think you can
solve without DNSSEC; perhaps it might be useful for you to enumerate
them.
> Always initiate the call yourself. Always check the nonce in the
> answer. Never accept unsolicited data. Never accept answers to
> questions
> you didn't ask.
And, according to your theory, be happy that you have no way to
validate the authenticity of any answers you do get?
> Besides, if you don't trust IP addresses
If?
We have meandered from the topic at hand, a bit. But the general point
I was trying to make was that all the robust DNS software in the world
will not avoid the propagation of rogue DNS answers if there's no way
for a client (or a trusted, validating resolver) to verify the
authenticity of the data contained within them.
Joe