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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf