Phillip Hallam-Baker wrote: > > The attack surface is the number of paths that are open to an attacker. > > In the current model there is only one trust path, the PKIX path. > > In the new model, the attacker has a choice of trust paths, the PKIX path > and the DNSSEC path and they can attack either of them.
The PKI-based attack surface includes each and every single CA that is signed under one of the existing >100 pre-configured trust anchors shipping with browsers. An attacker is free to choose to attack any single one of these CAs and/or their issuing/validation procedures. Trusting Certificates that are distributed under protection of DNSSEC would amount to one additional trust anchor. > > The problem with the DNSSEC path is that it is vulnerable to attacks against > the information input to the DNS system. The weakest link there is the > safeguards on registration of the DNS names. It seems that you do not realize that the entire TLS PKI security model, as far as the automatic / no-prompt "server endpoint identification" is concerned, has always been relying completely on that DNS data being accurate. Therefore, security-wise, trusting Certificates that are distributed through DNSSEC for no-prompt server endpoint identification is more secure than the TLS PKI pre-configured trusted scheme, and it does not add any new attack surface. Only when server certificates are manually verified by end users, other information from these certificates besides the DNS f.q.d.n might be considered in the end users decision to trust a server cert. But keep in mind that few TLS clients (such as browsers), currently support "pinning" of PKIX-authenticated server certs, so that on future connects only the very same server cert (with user-authenticated attributes other than DNS f.q.d.n) will be accepted from that server. In is very common misbehaviour in TLS clients to accept arbitrary other server certs on future connects, as long as the DNS f.q.d.n matches. One thing that needs to be addressed/solved is the key/cert rollover for any TLS-Server, so that it is possible to list more than one server cert as "valid" for a Server through DNS, at least for the time of the transition/rollover. -Martin _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
