The Future of Authenticating Websites (FAWN) - 1

The recent hack of DigiNotar and the resulting upheaval (it was even discussed in Dutch parliament yesterday), has made painfully clear that the current system of certifying websites is insecure and needs replacement. During a discussion on this topic with my colleagues of the Digital Security group of the Radboud University Nijmegen, the following issues and ideas came up. I'd like to share them with you, and welcome any comments you may have.

Some remarks on the problem

Concerning the scope and cause of the problem, it was noted that the found weakness will probably be exploited only by governments, not criminals. Governments have the means to control large parts of a the national Internet. For criminals, it is easier to attack victims using Trojans and viruses. This has some ramifications for the attack model to consider when trying to improve the certification system used by SSL. Moreover, we have to trust our browser to function correctly.

Although it might seem that there is not a single root CA in the current certification model, the browser vendor actually acts like a root CA (for all the 'root' CAs it includes in its browser). As there are several different browser vendors, the current model actually has more than one root, although the nodes and leaves in those certificate trees are shared.

Some CAs are too big to fail. Comodo was hacked before DigiNotar was, but could not be removed from the list of trusted CAs because then a significant portion of all secure websites would suddenly have become untrusted by the browser (until the website obtained a new certificate).

Requirements

During our discussions a few requirements that a potential solution should have to deal with came up.

• Any solution should be user centric. Meaning that the solution is easy to use for ordinary Internet users, helping to protect them in an intuitive and non-obtrusive way. Also, users should be able to decide for themselves who to trust or not.
• Trust is dynamic. It comes on foot and goes on horseback. Any solution should be able to cope with sudden changes in trust relationships, both on an individual and a national or global scale. Moxie Marlinspike calls this trust agility.
• Given this requirement, a solution should ideally not rely on a single trusted third party (because in such a case it is hard to lift the trust in this party). Note that even a sub-CA in certificate tree is such a trusted third party (for those websites that it issued certificates to).

Potential solutions

The following ideas towards solving the problem of authenticating websites were suggested.

• Since you have to trust your browser anyway, why not hardcode the certificates of the 1000 most important domains in the browser.
• Add redundancy. Websites should have more than one certificate, issued by different CAs. If one such CA is no longer trusted, it can be removed from the list if trusted CAs and the website can immediately use on of the remaining certificates for authentication.
• Use out of band signalling, like printing the fingerprint of a certificate on the bank card (so the certificate of the Internet banking site cannot be spoofed). Perhaps QR codes can be used for this purpose (as a particular instance of mobile identity management.
• A CA should only sign certificates for a domain, if the domain has a business relationship with the CA. This relationship should be registered, like a marriage register.
• Similarly, a certification authority should only issue a certificate for a domain if the domain cooperates.
• Perhaps identity based cryptography can be used to directly link a domain name with the corresponding public key, avoiding the use of certificates altogether. One can only get the corresponding private key if one can prove to own the associated domain.

I will not elaborate on other approaches I discussed earlier (like using DNSSEC with DANE, Perspectives or Convergence).

On the name of this topic

This topic is not called: "the future of certification of Internet websites" or something similar, because using certificates is but one way to authenticate websites. (Moreover, using the term certification implicitly implies that the website has undergone some kind of audit process before being issued a certificate; this is typically not the case.)

The real issue at hand is how to authenticate a website. That is the problem that needs to be solved.