full-disclosure - Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200807160212.m6G2Cxpm022058@drugs.dv.isc.org>
Date: Wed, 16 Jul 2008 12:12:58 +1000
From: Mark Andrews <Mark_Andrews@....org>
To: Paul Schmehl <pschmehl_lists_nada@...rr.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
	Discussion)


> --On July 16, 2008 11:17:07 AM +1000 Mark Andrews <Mark_Andrews@....org>=20
> wrote:
> 
> >> The real problem isn't signing or resigning zones, or even
> >> successfully=3D20 completing the original configuration (although those
> >> are not trivial for=3D20 the average person trying to setup their own
> >> dns).  It's the trust=3D20 anchors.  Until the root is signed, trust
> >> anchors are a PITA.  And until=3D20 the root is signed, why should =
> anyone
> >> believe that DNSSEC will achieve=3D20 wide adoption?
> >
> > 	Well there are a number of ccTLD's that are already signed.
> > 	RIPE sign their part of the reverse space.  ORG is in the
> > 	process of getting signed.  It's happening.
> >
> > 	There are existing solutions to dealing with lack of support
> > 	in the infrastructure zones (includes the root).  You let
> > 	someone you trust collect the trust anchors for you then
> > 	incorporate them on a regular basis.
> >
> > 	We effectively do this everyday with https but for some
> > 	reason people are scared to do the same thing with dns
> > 	despite private parts of the keys never being available to
> > 	the entity doing the certification.  With https the certifying
> > 	authority can spoof any site they certify.
> >
> 
> Perhaps that's because a cert problem on a web server breaks a single=20
> webserver.  A cert problem with dns breaks an entire domain.

	And a signed root changes that how?  You either add your
	trust anchor to a reposititory or to the parent zone.  You
	still need to re-sign regularly.  You still have the same
	amount of communication to do when you roll over your keys.

	B.T.W. DNSSEC problems are easier to chase down than a
	broken delegation.  I've done both.  Neither requires more
	than "dig" and "date".

	If you are really worried about validation failing you can
	always disable it but please sign the zones so that those
	of us who would like to be able to use DNSSEC to validate
	DNS data have something to work with.
	
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@....org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/