From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 02:47:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 524BC1065686; Wed, 23 Jul 2008 02:47:06 +0000 (UTC) (envelope-from prvs=pschmehl_lists=0832cde34@tx.rr.com) Received: from ip-relay-001.utdallas.edu (ip-relay-001.utdallas.edu [129.110.20.111]) by mx1.freebsd.org (Postfix) with ESMTP id 09FAF8FC2F; Wed, 23 Jul 2008 02:47:05 +0000 (UTC) (envelope-from prvs=pschmehl_lists=0832cde34@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,235,1215406800"; d="scan'208";a="4892722" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-001.utdallas.edu with ESMTP; 22 Jul 2008 21:18:13 -0500 Received: from [192.168.2.102] (cpe-24-175-90-48.tx.res.rr.com [24.175.90.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id AD46123DDF; Tue, 22 Jul 2008 21:18:13 -0500 (CDT) Date: Tue, 22 Jul 2008 21:18:11 -0500 From: Paul Schmehl To: Mark Andrews Message-ID: <616A73D0F163394E96936E69@Macintosh.local> In-Reply-To: <200807230046.m6N0khvt008606@drugs.dv.isc.org> References: <200807230046.m6N0khvt008606@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Munged-Reply-To: To reply - figure it out MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========79D675BB9A887D4CB823==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 02:47:06 -0000 --==========79D675BB9A887D4CB823========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On July 23, 2008 10:46:43 AM +1000 Mark Andrews =20 wrote: >> >> I just played around with it recently. It's not that easy to >> understand initially *and* the trust anchors thing is a royal PITA. >> >> Once you implement DNSSEC you *must* generate keys every 30 days. So, >> I thin k, >> if you're going to enable it by default, there needs to be a script in >> period ic >> 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. > > WRONG. > > You need to re-sign the zone an expire period before the > signatures expire. You need to generate new keys periodically > but no where near every 30 days. > OK. I misspoke. I got the 30 days from Andrew Clegg's presentation and=20 confused keys with signatures. But still, you have to resign *every* zone = every 30 days. "Signatures have lifespans =E2=80=9CBorn-on=E2=80=9D date =E2=80=93 1 hour prior to running dnssecsignzone Expiration date =E2=80=93 30 days after running dnssecsignzone Expired signatures lead to zones that will not validate!" I followed Clegg's presentation to try out dnssec. Then there's this: "Any time you modify a zone =E2=80=93 or at least every 30 days (minus TTL) you must re-run dnssecsignzone If you don't 1) Zone data will be stale 2) Zone data will be GONE" So, for me, that's three zones I have to mess with every 30 days. Then=20 Clegg says the the ZSK keys should be changed every quarter and the KSK=20 keys every year. So I have to resign monthly, regen ZSK keys quarterly=20 and regen KSK keys annually, and I have to do this without breaking any of = my zones so that they stop resolving for periods long enough to clear out=20 caches. How is the average person supposed to understand this, much less do it=20 correctly? Don't misunderstand me, Mark, I'm all for security. But this=20 ain't easy, and the online information only confuses the issue. Clegg also says this: "When finished: 2 ZSK files (.key and .private) 2 KSK files (.key and .private) 2 zonefiles (unsigned and .signed)" So, do I have to have two zone files or not? As someone who is trying to=20 understand this new technology, I have to tell you, the online=20 documentation isn't written for non dns-gurus. I'll be happy to sign my zones, but not until I understand how it works,=20 what the ramifications are and what my maintenance responsibilities are. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. --==========79D675BB9A887D4CB823==========--