Why TLS 1.3 is NOT born dead

// under cryptography architecture kerberos tls

Given the predictable future of Quantum Computing, the design of TLS 1.3 is at risk, and an upgrade might be a bad idea, in spite of the many improvements to the security design. We explain why and how TLS 1.3 can be a blessing in terms of just this danger.

We are facing a grim future. In a few years, the now-active development of Quantum Computers will break our backs and bones and this is why the ARPA2 project has a road map for getting over Quantum Computers which, incidentally, assumes the TLS will solve this problem in an integral manner for the entire Internet.

Pros and Cons of TLS 1.3

TLS 1.3 is a great improvement over TLS 1.2 in most other regions. As TLS 1.2 grew, many pathways were added that complicate the design of implementations. Some code portions are then barely tested, and unprecedented combinations of such code portions have no purpose in proper use cases, but may still help to abuse the protocol. The redesign of TLS 1.3 solves many such problems by being much more simple. This is an incredible benefit to the security world.

TLS 1.3 does not prevent attacks by Quantum Computers. In fact, it might be said that it plays Quantum Computers in the hands by always using ECDH key establishment and using mechanisms to sign for the keys. Note that this is also the advised use for TLS 1.2, so it merely establishes a commonly advised practice. The problem however, is that it is now enforced, even though ECDH is known crackable with Quantum Computers.

One might say that a new TLS 1.4 is needed to avoid that, and that TLS 1.3 is born dead. The trick however, is that so-called cipher suites can be added to to protect from Quantum Computers. We developed such a cipher suite for TLS 1.2 and TLS 1.3, so that no upgrade to TLS 1.4 is needed. There is no Quantum Proof replacement for ECDH yet. As soon as one is found and established as secure, there is a very good reason for TLS 1.4, but not until that. Until then ECDH is very useful, we should just use it well.

Explaining ECDH

Let's say we can multiply by 3, but we have no way of reversing that. That is not really true of course, but it is a simple model of the kind of things that more complex cryptographic algorithms do; they work one way but have no reverse. The danger of Quantum Computers is that they break assumptions about the operation of computers, and this means that the reverse operations (division by 3 in our model) are available to those who have such a device.

This is how ECDH works:

The client and server picks long random numbers, let's call them C and S respectively.
They each make the irreversible multiplication by 3. They keep hold of the original random number, but consider it secret.
They pass the multiplication result to the other, so the client and server receive 3*S en 3*C, respectively.
Each now combines the received value with the secret random number. The client finds C*(3*S) and the server finds S*(3*C). When the actual operation, which is not multiplication, has the properties of changing the order and brackets (commutativity and associativity), then both are equal to 3*C*S. In short, they have the same value. A master key can be derived for that, and can be used in TLS.
The trick of ECDH lies in the fact that the end points are ahead of the game, knowing information with one less multiplication-by-3. Adversaries that observe the traffic see 3*C and 3*S and end up with 3*3*C*S which has one irreversible multiplication by 3 more than is needed to construct the master key.
Note that TLS does more than this; most importantly, it authenticates the key exchange to thwart man-in-the-middle attacks. It also explains how to continue with the master key, and protect further traffic so it is private and authentic.

A very important feature of this setup is that it uses fresh random data on every new connection. As a result, if someone were to crack one TLS connection it would not be able to crack another. Another valuable asset is that the party providing the credentials for authentication of parties cannot decrypt the value 3*C*S if it sees the flow of traffic.

Using ECDH Safely

The "only" problem left in ECDH is the Quantum Computer. They will be able to crack and infer 3*C*S from 3*3*C*S. And this is a big problem, because TLS connections may be stored today with the intention of deciphering them in the future. Your credit card numbers and passwords that were assumed to be safe under the cloak of TLS suddenly lay barren to the eyes of those with the funds to own a Quantum Computer. This is not only an assault to the privacy of individual users, but it also creates immense inequality.

The trick, then, is to incorporate further secret information that cannot be known to such forceful parties. This is difficult in itself, because it needs to come from a source that is preferrably controlled by the end points in the game, not some central party that may be coerced into cooperation with those who own Quantum Computers.

The additional secret means that the client and server have a shared key K on top of their local secrets C and S. They send 3*C and 3*S and each can compute 3*C*S*K -- observers would still see 3*C and 3*S but they can reduce 3*3*C*S to 3*C*S because Quantum Computers would allow them the division by 3. They still have no access to K though, if it is passed in a manner out of reach of a Quantum Computer. (Note that an alternative scheme might pass 3*C*K and 3*S*K over the wire, and the adversary would have 3*3*C*S*K*K and, not knowing K, they should not be able to divide it out of 3*C*S*K*K either. It is questionable if this is in any way better though.)

Certificates are no help when it comes to this, as all current-day public-key crypto is bound to fail. Thankfully, some solutions exist there too. But for now, all we have is symmetric crypto, which is considered safe from Quantum Computers. And if you need an infrastructure for symmetric crypto then there is one obvious source: Kerberos.

Kerberos is very old and yet, has withstood the pressure of time. It has its problems, but none as devastating as the threat of Quantum Computers. Very useful is that it logs on to all systems, both web and non-web, with a single login each day. It has a place in virtually all the protocols, it is flexible and very easy to use. In fact, single-signon systems are constantly being proposed for the web (which in itself means it is not at all single-signon; there is more to the Internet than just the web and some are more user-friendly than you might think).

Enter TLS-KDH

Our integration of Kerberos with TLS is general in nature, and happens to also solve another problem, namely the lukewarm security of Kerberos for HTTP. The TLS-KDH cipher suite uses Kerberos for authentication of the ECDH exchange, and it uses ECDH for key agreement. By incorporating a session key from Kerberos as K in the ECDH exchange, we establish a stronger security level, namely one in which the Kerberos administrator must be part of the game of cracking the security of the connection with a Quantum Computer. And the Kerberos administrator is usually local and trusted to protect the interest of the domain it identifies.

The protection starts as soon as TLS-KDH is introduced. It does require the authentication of a client, but there are forms of anonymous identity in Kerberos, and at least the form that releases the domain but not the user identity is implemented.

There are two forms of TLS-KDH:

KDH-only uses nothing but Kerberos credentials and ECDH to construct the master key for TLS. The server may provide no key, or it may allow user-to-user (or peer-to-peer) TLS connections if it passes an opaque handle to its own Kerberos session.
KDH-enhanced uses common certificates but the client continues the connection by providing Kerberos authentication. In this case, the certificate-based security is enhanced with K too, causing the same benefits as with KDH-only, just after starting the TLS connection in a more generally accepted manner. We believe this can be useful to offer a mixed service that allows both TLS-KDH and traditional session protection.

Where to get TLS-KDH

We are offering TLS-KDH in a number of manners:

We built it into GnuTLS. There it is one of the mechanisms available for TLS 1.2 as well as TLS 1.3. See the advise above about our strong recommendations to upgrade to TLS 1.3 and not consider it born dead. You may however want to trim the list of cipher suites if you are concerned about current-day tapping of TLS connections for upcoming-future cracks with Quantum Computers.
We are building it into mbedTLS.
We have incorporated GnuTLS with TLS-KDH into our TLS Pool product, and may in future releases add support for mbedTLS as an alternative TLS driver underlying the TLS Pool. The intent of the TLS Pool is to separate the concerns of TLS and keys from the applications, and offer it a simple API over which it only needs to be concerned with the identity of peers.

If you use and like these products, please support it in your applications and be loud about it. We should not panic about Quantum Computers, but we should realise their devastating impact on today's security and even its risk of creating inequality and, as with any other problem, solve it with better technology.

This is work from early phases of the InternetWide project. If you like where we are heading, then please read more about our work, and think about adopting that too. We are in the game for an Internet that is much more distributed, self-controlled and certainly more private and secure than what we have today.

Go Top