[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


to: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se
From: Mark.Andrews@isc.org
Date: Tue, 16 Jul 2002 15:50:08 +1000
In-reply-to: Your message of "Tue, 16 Jul 2002 14:04:32 +0859." <200207160504.OAA02957@necom830.hpcl.titech.ac.jp>
Sender: owner-dnsop@cafax.se
Subject: Re: dnssec discussion today at noon


> Mark;
> 
> > 	And what does this have to do with DNSSEC?
> 
> The theory explains the reality that public key cryptography
> (including DNSSEC) is not used for serious purposes.
 
	No.  It explains why it may not be useful for some purposes.
	In no way does it demostrate that it not useful for DNSSEC.

> The theory can be used to explain some (or most or all) of
> operational difficulty of DNSSEC deployment.
> 
> > 	DNSSEC is designed to allow you to verify that the data you
> > 	receive from the DNS is that which was entered.  That your
> > 	transactions havn't been spoofed.
> 
> Such security is not useful for serious purposes, when no one is
> really responsible if your transactions are spoofed.

	Actually once DNSSEC is available there is a person responible
	if the data spoofed.  The person that entered the data in such
	away that it could be spoofed.

> So,
> 
> > > We can live with the weak security, security level of which is,
> > > with proper 3 way handshaking with cookies, equivalent to that
> > > of the telephone network.
> 
> Just as you can rely on people operating name servers, you
> can rely on people operating routers.

	Getting routers fixed to block spoofed traffic relies on
	*everyone* doing the right thing.  Getting DNSSEC working
	only requires that the operators of the root servers, down
	to the zone servers do the right thing.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

Home | Date list | Subject list