Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Apr 1999 07:44:17 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Jay Tribick <netadmin@fastnet.co.uk>
Cc:        freebsd-security@freebsd.org
Subject:   Re: ssh and scp
Message-ID:  <Pine.BSF.3.96.990408073528.10539B-100000@fledge.watson.org>
In-Reply-To: <19990408105956.M2213@bofh.fastnet.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Apr 1999, Jay Tribick wrote:

> > 1. BIND 8.2 already supports (part of) DNSSEC.
> > 2. But there are known bugs in the 8.2 implementation which can give
> > you crashes if it's used. An unofficial patch is available.
> 
> Am I right in thinking that it doesn't encrypt the transfer,
> just signs it so that it can be authenticated?

This is intentional--DNS is not intended to provide privacy, in this case
only integrity and authenticity.  While BIND supports some access control
on the release of full zones currently, the fundamental design as public
name service makes that only a secondary goal.

This is especially the case if you look at DNSSEC NXT support -- that is,
the authenticable denial that a particular name exists.  This is done by
having signed records that describe the gaps between legitimate records
(i.e., a record that says, the next record in the zone is named
blah.blah.blah).  A technique named NXT-walking is described, in which an
attacker can retrieve a well-known record in the zone, and then walk down
the zone using the NXT records to retrieve all the other names.  There was
some talk of changing the NXT records to use a one-way hash of some kind
on the second name, but I haven't followed DNSSEC closely in a number of
months (too many RFCs, too little time).

DNSSEC has enourmous potential; now if only we can prevent DNS politics
from screwing it up.  It can provide a public key infrastructure bound to
a well-known naming scheme; for example, you can stuff web server and SSH
keys into zones, and be able to walk securely down the DNS hierarchy in
the style of a certificate hierarchy.

And of course, there is that problem of the root key...

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services             http://www.safeport.com/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990408073528.10539B-100000>