Basil Dolmatov wrote: > > > 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. DNSsec, as far as I can see, does not use a PKI in the traditional sense. There are _NO_ persons involved in the process, it is a pure authorization hierarchy of signing keys, and the distribution of that keys could be coupled to the lease of DNS domains from registries but is technically independent. > > 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? Current DNS comes without any kind of protection and without any kind of trust. Get rid of your trust idea and adopt DNSsec only for the possibility to add some level of integrity protection and data origin authentication into the system. There are going to be so many keys and so many entities, so many key renewals and so many fully automatic signature operations in place that it will be impossible to come up with a universal set and number of "trusted authorties" that will make the entire DNS trusted and secure for everyone. The best you can come up with is to individually manage risks for specific zones to match individual threat scenarios, and you can do that completely indepent of how many "roots" there are. Going for one single root is an arbitrary choice, but it happens the one that is the easiest to deploy and the one with the lowest risk of operational problems (interferences among roots is a problem that can not exist then). Sensible DNSsec risk management can only work at the level of individual zones. It is not going to work with a single or a set of roots alone. Therefore discussing how many roots there should be and who should run them is a complete waste of time. The initial adoption rate of PGP and SSH was never crippled by discussions of which roots you want to trust. Otherwise they would have failed just as badly as S/MIME. TLS only became popular because the vendors decided to completely ignore risk management and selection and management of trusted roots. The choices are completely arbitrary and hardly anyone cares about the complete lack of risk management. When I use my Web-Browser to connect to some bank or online-shop under protection of SSL/TLS, then I don't have any trust to that bank or shop, not to their ISP and not to the CA that issued the cert for the server. Although the entire architecture is pretty insecure because of a complete lack of trust in many involved parties, it is far from being useless. Would the change from traditional DNS to DNSsec have a security impact on that scenario? No, NONE at all. But it could make the communication infrastructure more robust against infrastructure attacks. Managing risks would mean to manually check the server certificate and compare it to some out-of-band verification information. Browsers are quite hostile to risk management, because they don't naturally support concious trust decisions in the traditional SSH-style, which makes individual risk management extra painful. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf