“Do We Need an Alternative to HTTPS and TLS?” This question came up in the Personal Clouds list recently. Thanks to the well publicized problems with Certificate Authorities, variations on this question are a common theme among many of the communities in which I participate. The CA has become the whipping boy for all the ills of authentication and network security. Let’s just get rid of it, right? It’s not that simple.
Although we may dislike certain aspects of a CA or other central authority, any replacement system would need to provide certain functions of that role or else mitigate the issues introduced by their absence.
The X.509 cert binds a bare asymmetric key to an identity and policies. The CA’s role…
- Manages the namespace to ensure no dupes in the DN or Serial number.
- Enforces policies against the identity and restrictions bound into the cert.
- Vouches for the identities bound to the certs.
- Binds the keys, identity and policy prior to first use ensuring that they do not change.
- Provides a revocation service.
I’ve been spending a lot of time lately in Steve Gibson’s newsgroups where they are developing a new authentication technology based on bare 256 bit random keys. Members of the group are extremely fond of calculating highly improbable birthday attack odds and saying things like “Bruce Schneier says ‘trust the math'”. The assertion is that it is OK that the system allows dupe keys because of the “vanishingly small” chance of one ever occurring. I do trust the math. I hold the code in somewhat lower esteem. As a security architect it doesn’t matter to me how small the chance of a dupe is. If the identity *can* be ambiguous, I assume that a dupe *will* occur and design controls to mitigate the impact of that occurrence. The CA system was built on similar principles. It assumes that dupes would occur and several layers of controls, in addition to randomness and large keyspaces, were included in the architecture to detect and eliminate them.
When I consider replacing the CA with a decentralized identity scheme the first thing I start asking is how the proposed system, lacking management of its namespace (or keyspace), deals with ambiguous identifiers. One thing I’ve come to realize is that anonymity means ambiguity. A system relying on bare keys and nobody to manage the namespace cannot distinguish between two holders of the same bare key. Assuming this is solved (or at least considered), then I start looking at how the proposed system addresses some of these other issues.
HTTPS provides a few things that can be easily duplicated and a few things that cannot. Since the user typically authenticates by sending credentials within the secure TLS tunnel, then an anonymous protocol to generate a random session key can work. It doesn’t matter if two TLS sessions generate the same session key so long as it cannot be predicted. That part we can do easily. On the other hand, we also use TLS to authenticate the server. Here we really *do* care about ambiguities of the identifiers, the policies bound to the certificates, the ability to revoke keys, that the identity provider relied on has no stake in the connection, etc.
I’m not suggesting that working towards alternatives to the CA system is bad or hopeless. But whatever we might consider to replace HTTPS, we need to remember there’s a baby in the CA bath water. It may be hard to see through the blinding glare of all the crypto math, but it’s in there and is worth saving.