Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 13:48:56 -0700

Sam,

	If someone is going to go to the trouble of deploying an IDS
that is intelligent enough to do what you propose and they are 
going to have someone monitor it at minimum wage then they are going
to be able to afford whatever it ends up costing in time, effort and
so on to enable DNSSEC.

		Phill

> -----Original Message-----
> From: Sam Weiler [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 10:15 AM
> To: [email-masked]
> Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN
> 
> 
> On Wed, 30 Apr 2003, Hallam-Baker, Phillip wrote:
> >
> > 	What value do you claim there is to securing the 
> delegation without
> > any security on the delegated zone?
> >
> > 	There has been a lot of security analysis on this 
> issue, the only
> > security issue that has been raised is that of preventing 
> an insertion
> > attack, a risk that is not relevant to a domain where 
> anyone can buy a
> > domain.
> 
> There's also the deletion ("spoof a zone out of existence") attack.
> You can still replace the NS and make the zone unreachable, but you
> could have done that just by stomping on the whole answer; DNSSEC
> doesn't guarantee that packets get through.  Without opt-in, assuming
> you get an answer at all, you at least get a verifiable statement of
> existence -- you know that such a delegation exists and that something
> is preventing you from reaching it.  That could trigger an IDS's alarm
> bells, or it could tell you that you need to try harder to get the
> answer.
> 
> Assuming that methods for "trying harder" are developed, you probably
> don't want clients trying them all the time -- they'll probably be
> bandwidth intensive or they'll try to get around caches and end up
> pounding authoritative servers into the ground.  As an operator of
> authoritative servers, your employer may be interested in minimizing
> those events.  One way of doing that is to provide a very clear
> trigger for when it's required.  You don't want all NXDOMAINS to turn
> into a "flail on the auth servers" fest.
> 
> -- Sam
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>