Date: Tue, 22 Jul 2008 19:11:46 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Doug Barton <dougb@FreeBSD.org>, freebsd-stable@freebsd.org, Paul Schmehl <pschmehl_lists_nada@tx.rr.com> Subject: Re: FreeBSD 7.1 and BIND exploit Message-ID: <20080723021146.GO76659@elvis.mu.org> In-Reply-To: <20080723015855.GA36829@eos.sc1.parodius.com> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> <20080723015855.GA36829@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy, I can't agree with you more, for some reason
crypto people seem to believe that in order to drive
a car you should have to know how to rebuild a carb.
Makes no sense.
The funny part is that your comparison with setting up
IPsec is the same thing that I compare these things to.
Back in 2003 I tried to set up a "shared key" IPSEC dhcp
at home, basically I'd just make a key and sneaker-net it
to the hosts that wanted to connect, after about 6 hours
I just gave up and used "wep".
*sigh*
-Alfred
* Jeremy Chadwick <koitsu@FreeBSD.org> [080722 18:59] wrote:
> On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote:
> > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton
> > <dougb@FreeBSD.org> wrote:
> >
> >> Matthew Seaman wrote:
> >>
> >>> Are there any plans to enable DNSSEC capability in the resolver built
> >>> into FreeBSD?
> >>
> >> The server is already capable of it. I'm seriously considering enabling the
> >> define to make the CLI tools (dig/host/nslookup) capable as well (there is
> >> already an OPTION for this in ports).
> >>
> >> The problem is that _using_ DNSSEC requires configuration changes in
> >> named.conf, and more importantly, configuration of "trust anchors" (even for
> >> the command line stuff) since the root is not signed. It's not hard to do
> >> that with the DLV system that ISC has in place, and I would be willing to
> >> create a conf file that shows how to do that for users to include if they
> >> choose to. I am not comfortable enabling it by default (not yet anyway), it's
> >> too big of a POLA issue.
> >>
> >
> > I just played around with it recently. It's not that easy to understand
> > initially *and* the trust anchors thing is a royal PITA.
>
> I completely agree on both points. To give you some idea of how much of
> an annoyance DNSSEC is, a friend of mine who used to work at Nominum
> stated that one of their software engineers, when signing, on had a
> clause appended to his employee agreement stating he would not be
> required to work on DNSSEC code, due to the absurd complexity of it all.
>
> For what it's worth, I went looking into DNSSEC last week, and after a
> few hours of skimming then reading, I concluded it's over-engineered and
> adds too much hassle for it to be considered a worthwhile "upgrade". In
> no way am I putting down the need for security, but the added complexity
> is what's going to turn people off to this, and because of such, very
> likely ignore it. You can call me ignorant/lazy -- I welcome such --
> but I guarantee others feel the same way.
>
> DNS, for most people, is expected to be a "simple thing". They like it
> to be simple, and it's generally not rocket science. People have come
> to expect that, and while I think most are willing to accept change
> (take TSIG for example), it has to be easy to set up, simple to
> maintain, troubleshooting outlined step-by-step with easy-to-follow
> output, and in the case of a hard failure, the documentation easy to
> understand.
>
> This is not the case with DNSSEC; I feel like I'm setting up a bloody
> IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES
> with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust
> anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its
> phases, KSK and its phases, etc...
>
> There's the "how to make it work in 6 minutes" PDF by the ISC, which
> appears to have been made/used for/as presentation material -- meaning
> you're missing the verbal explanations that go along with each item.
> There's also inconsistencies in configuration syntax within the PDF,
> making you wonder how much time someone put into it.
>
> There also appears to be an assumption made throughout all of the
> documentation that I've read: that your recursive and non-recursive DNS
> servers are separate. I'm still trying to understand why that
> assumption is made; sure, the majority of the "enterprise-class" world
> has segregated DNS servers (public authoritative vs. internal recursive
> resolvers), but the runner-up would be administrators who simply run
> BIND on their servers and use two simple configuration lines:
>
> acl "trusted" { my.net.block/cidr; 127.0.0.1; };
> options {
> allow-recursion { trusted; }
> };
>
> If DNSSEC really requires that your recursive and non-recursive servers
> be separate, then it will fail.
>
> And I still cannot get over the fact that this "HOWTO" is 47 pages long:
> http://www.nlnetlabs.nl/dnssec_howto/
>
> Let's not forget this packet flow diagram, which is quite legible and
> easy to understand:
> http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png
>
> > Once you implement DNSSEC you *must* generate keys every 30 days. So, I
> > think, if you're going to enable it by default, there needs to be a
> > script in periodic that will do all the magic to change keys every 30
> > days. Maybe put vars in /etc/rc.conf to override the default key lengths
> > and other portions of the commands that could change per installation.
>
> I believe you're talking about re-signing the zones. The duration is
> adjustable, but 30 days appears to be what the documentation and howto
> site defaults to/recommends using:
>
> http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html
> http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4
>
> > But until root is signed, it's not worth it for those of us who don't
> > have dedicated staff doing dns only.
>
> Bingo.
>
> --
> | Jeremy Chadwick jdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
--
- Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080723021146.GO76659>