With our TLS Pool, we are aiming at a wide variety of possible
security mechanisms. The reason being, we would like to have more than
one secure mechanism ready; if we encounter a problem with one we can
then substitute another. In that light we are innovating on a few of
the TLS CipherSuites.
With our TLS Pool, we are aiming at a wide variety of possible security mechanisms. The reason being, we would like to have more than one secure mechanism ready; if we encounter a problem with one we can then substitute another. In that light we are innovating on a few of the TLS CipherSuites.
Perfect Forward Secrecy
Most current work on TLS assumes that we establish a property called Perfect Forward Secrecy. What does that mean?
Recall that security is based on certificates. This certificate contains a key, and it is valid as long as the certificate is in use, often for a duration of 1 to 3 years. For some of the highest-profile sites, it may be interesting to crack the keys in use.
Of course, keys are selected to be long enough to make this unpractical. But that does not mean that future developments could not cause a crack on such keys; we never know for certain that such things can never happen. In addition, truly rogue crackers might try to break into a server and gain direct access to a private key, in which case the size of the key is immaterial.
Given a private key, an attacker can do two things; first, it can fake being a site (meaning that a certificate must then be retracted and replaced with another immedately) but it may also look back to recorded TLS-traffic from the past, and try to decyrpt that. Perfect Forward Secrecy is the property that says that this cannot be done.
Not surprisingly, modern deployments of TLS take this important property into account, in the interest of protecting the privacy of their traffic.
TLS-KDH adds Kerberos to TLS
We are working on a long-felt need to bring two frameworks for online security together, namely Kerberos and TLS. The Kerberos world is very good at access to all sorts of services, such as email, shells including database connections, remote file access and so on. Strangely, it does not have a very good solution for secure access to websites. There are a few halfway solutions, but none of them is both secure and general.
With TLS-KDH we aim to fill this need for a general binding between TLS and Kerberos. The DH in KDH means Diffie-Hellman, which is a technical way of saying the Perfect Forward Secrecy is supported, another facility that Kerberos is longing for. Note that TLS is used a lot for the protection of secure connections, including for secure websites; it is what turns HTTP into HTTPS, basically.
Kerberos uses a type of algorithm known as symmetric. These algorithms are much faster than the public key systems that are otherwise being used for things like website certificates. In fact, it is surprising how clever Kerberos is in using these relatively simple algorithms and build an infrastructure on it. It does have the problem that a few central nodes, namely the Key Distribution Centres, have knowledge of all the keys in use and could potentially decrypt all traffic under their reign, but this is resolved with the addition of Perfect Forward Secrecy in TLS-KDH.
Future Preview: Kerberos with Impromptu Realm Crossover
The web is a world-wide system, and TLS-KDH is based on Kerberos, which is not. At least, not yet. This means that TLS-KDH is highly useful for a secure realm's internal services, and perhaps some that were explicitly incorporated in a federation-style, but TLS-KDH cannot currently connect the entire Internet securely.
The thing is, Kerberos bases everything on securely established relations between secure realms. This is model breaks the possibility of gaining access to arbitrary remote services with Kerberos, and thus with TLS-KDH.
This problem can however be solved in today's World, because we now have a globally signed, vendor-neutral infrastructure named DNSSEC. In addition, we have something called DANE that permits us to affirm service's certificates in this signed infrastructure. Combine the two, and it is possible to gain trust in a remote party, without any need for a mutually trusted certificate authority other than the technical providers of the DNSSEC infrastructure.
Based on this, it is possible to achieve what could be called "Impromptu Realm Crossover" with Kerberos. We have a project running to test the ability to do this right now.
Combining Impromptu Realm Crossover with TLS-KDH, we arrive at an infrastructure that can establish the Kerberos system. We have known this since we started designing TLS-KDH, and although the mechanism is going to be useful for in-house secure connections such as to internal websites, it will automatically upgrade to the entire Internet when we get Impromptu Realm Crossover in place!
Future Preview: YourRealm
Given that we are forecasting an Internet where Kerberos is everyone's friend, and indeed the richness of this highly developed authentication system enables secure access to services anywhere, we are left with the problem that not everyone currently has a Kerberos setup.
But how about people without a hosting provider? For them, we envision public identity providers, perhaps as a service of an online shop that you frequent, as part of a family or corporate domain name, or as a general and independent service. It is for these types of service that we are developing YOURREALM.ORG; this system establishes your online identity with a sufficient degree of certainty, and then provides the cryptographic mechanisms that make it easy for other players to act on it. And of course we have Kerberos close at heart when designing this system.
Secure Remote Passwords
A final mechanism worth mentioning is Secure Remote Passwords, or SRP for short. This mechanism is gaining popularity because it is not just any other password mechanism, but comes with very advanced cryptographic properties.
First, SRP establishes an encryption key that has the Perfect Forward Secrecy property. Second, and much more impressive, it also is what we call a Zero Knowledge Proof; the remote service can validate the password without actually getting to see it. The service cannot possibly use whatever it got to login to another website on your behalf, even if you used the same password for that site. That is so much better than the current web practice that it is mind-boggling.
SRP is a strong mechanism in itself, but we are trying to take it even a step further. We are trying to integrate the mechanism with secure tokens, usually in the form of a simple USB key, that hold the password and would never hand it off. Since the rest of the pathway is a Zero-Knowledge Proof protocol, this means that it will be impossible to authenticate with SRP without this token. So, unplug the token and further logins are disabled. This does a great thing for reliance on midly untrusted desktop environments.
Moving towards Elliptic Curves
Cryptography is moving towards Elliptic Curves, for reasons of compactness and efficiency. This is a new generation of cryptosystems, and in some cases they are in high demand. A place where they are especially called for is Diffie-Hellman, which is the mechanism to achieve Perfect Forward Secrecy.
For TLS-KDH, we are not going to use the older ("modular exponentiation") generation of Diffie-Hellman anymore. And our work on Kerberos will also center around the newer "elliptic curve" generation.
Another point where Diffie-Hellman is used is in Secure Remote Passwords. Here, the mechanism is entwined with the mechanism, so replacing it is not trivial. In fact, a number of competing alternatives is under discussion. Our work on showing SRP combined with a hardware token is meant to influence this discussion towards making similar things possible with a future "elliptic curve" generation of SRP.
A lot of talking
We do not accomplish all these things on our own. We are actively engaging discussions on these matters in the Internet Engineering Task Force work groups that relat to these matters, especially Kitten and the TLS WorkGroup.
Imagine a bunch of highly skilled technicians, openly discussing ideas and open to external input. Dropping an idea in those groups tends to raise both interest and a lot of technical feedback. It can be daunting, but is in fact highly challenging, to live up to the combined expectations of these top-notch engineers, most of which are highly skilled in a diversity of expertises.
I dare say, we have a thing or three cooking...Go Top