Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

[Martin Rex <[e-mail]>]

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