so much simpler to solve DNS vulnerabilities with dnsCurve http://bit.ly/cjmH2n
:) 2010/2/17 Phillip Hallam-Baker <[email protected]> > One mechanism that was unfortunately pushed asside as a result of the > fixation on end to end DNSSEC would be to for the resolver to use > DNSSEC (and other methods) to authenticate the data it receives and to > use some modification of TSIG to authenticate the communication > between client and resolver. > > This model does not make much sense if you stick to the model where > hosts pick up their DNS service from the local host. But it makes a > great deal of sense when you are using a service like Google's DNS. It > would not take a great deal of effort to graft a Kerberos like scheme > on to effect key exchange. > > > The real problem with DNSSEC is that it has taken so long that the > Internet has changed since. And rather than go back and redesign we > are always told that so much time and effort has been spent already > that we cannot possibly take any time to look at the issues that might > prevent deployment or use. And so instead of the opt-in fix taking six > months as it should have done it took six years and instead of the > zone walking/privacy issue taking six months it took four years. > > I am thinking of retitling my RSA talk '2010 The Year of DNSSEC'. > > > I am not trying to beat up people and say do it the way we did it. > What I am trying to say here is DON'T REPEAT OUR MISTAKES. Look at the > solution that we were forced to adopt when the single rooted hierarchy > proved undeployable. > > > On Wed, Feb 17, 2010 at 10:01 AM, Basil Dolmatov <[email protected]> wrote: > > Masataka Ohta пишет: > >> > >> But, the most serious defect of DNSSEC, or PKI in general, is that, > >> despite a lot of hypes, it is not cryptographically secure. > >> Social attacks on trusted third parties makes the parties > >> untrustworthy, which means PKI is merely socially or weakly > >> secure. > >> > >> > > > > There are a lot of deficiencies in PKI, but at present time I can see no > > alternative for establishing trust in loosely connected and large > systems. > > If there is one, please advise. > >> > >> For security of interdomain routing, social security of trust > >> relationship between ISPs is just enough to which additional > >> social security by PKI is not helpful. > >> > > > > There are no trust relationships between my ISP and your ISP. > > How my ISP can trust routing announce, which I have got over the network > and > > which has your ISP mentioned as the origin? > > > >> For security of DNS, social security of trust relationship between > >> ISPs and between zones are just enough to which additional social > >> security by PKI is not helpful. > >> > >> > > > > Same question applies to DNS. My resolver have no trust relationships > with > > your server. > > How I can trust DNS-answer which I have got over the network? > > > > Unfortunately, Internet 20 years ago and Internet today are two > > significantly different networks. > > > > 20 years ago I trusted to nearly all network participants and undoubtedly > > trusted to all network administrators. > > > > Now, the necessity to build the chains of trust is obvious, otherwise you > > will lose a lot. The methods, which are being implemented are definitely > not > > ideal (I knew a lot of flaws and weaknesses in systems, which are using > > PKI), but at the same time I do not know anything better. > > > > > > dol@ > > > > > > > >> Masataka Ohta > >> > >> > >> > > > > _______________________________________________ > > Ietf mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
