Assured is very happy that RFC8446 Transport Layer Security (TLS) 1.3 has been released. This article provides a brief TLS 1.3 overview.

What's new in TLS 1.3

• Simplifications, security improvements and removal of old legacy cryptography.
• Focus on reduced Round Trip Time (RTT) waits in handshake and in resume. Protocol should be fast and less impacted by network latency!
• New interresting 0-RTT resume feature: speed-vs-security trade-offs, where TLS opted to prioritize performance. Anti-replay security decisions to be handled application layers above TLS, for example by HTTP/2 servers,
• New, faster and safer Elliptic Curve options.
• RSA usage in TLS receives a major overhaul.
• Complete transition to AEAD (authenticated ciphers), bare CBC and bare Stream-ciphers removed.

Implementation status now (2018-08)

• Chrome web browser: implements TLS 1.3 by default.
• Major Web Hosts: Cloudflare, Google and other major providers allready support TLS 1.3.
• TLS 1.3 library today: BoringSSL, OpenSSL, WolfSSL implement TLS 1.3.
• TLS 1.3 library support in the works: ARM mbed tls has confirmed working on implementing TLS 1.3 support. Apple has had experimental support available for early testers since 2017 and can be expected to enable it for general use in future. Microsoft are "committed to delivering a 0-RTT experience in Microsoft Edge through HTTP 2.0, TLS 1.3, TCP Fast Open, and TLS False Start."

Testing implementations (your mileage may vary as this may depend on your version and what edge server you are connected to):

• Testing with Chrome-Cloudflare: TLS 1.3 (X25519, AES_128_GCM) is negotiated.
• Testing with Chrome-Google: Google QUIC (X25519, AES_128_GCM) is negotiated. (Google QUIC is a UDP based security protocol, not same as TLS 1.3).

Splitting handshake from record encryption

From TLS 1.2, we have grown used to cipersuites such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and occasionally wondering things like "why the quack isn't TLS_ECHDE_PSK_WITH_AES_256_GCM_SHA384 standardized if almost all of its subparts are standardized?".

TLS 1.3 finally resolves these problems and simplified TLS by splitting handshake from block record encryption:

The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC)."

i.e. now a ciphersuite is TLS_AES_256_GCM_SHA384, there is no handshake part in front of it.

Handshake ciphers: (EC)HDE, PSK-only, PSK with (EC)DHE

Forward secret with respect to long-term keys: If the long-term keying material (in this case the signature keys in certificate- based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key (see [DOW92]), as long as the session key itself has been erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" PskKeyExchangeMode.

Forward secrecy using Diffie Hellman variants is a must for TLS 1.3, no longer should a server key compromise lead to historical communication being subject to decryption using the server key.

The only exception is when symmetric pre-shared key (only) is used;

• (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
• PSK-only
• PSK with (EC)DHE

The key derivation function, the feature that generates a session from the handshake, has been re-designed:

The key derivation functions have been redesigned. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.

TLS 1.2 and earlier employed a homebrewed key derivation scheme that was, well, a very nice hack. The new key derivation scheme uses similar HMAC functions, but in a standardized and well analyzed KDF scheme.

RSA usage has been redesigned

A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), ...

RSA support in TLS has been overhauled:

• RSA decryption based handshakes are banned/removed. due to RSA not being forward safe.
• RSA signatures (authentication) is now performed using Probabilistic Signature Scheme (PSS).
• RSA PKCS#1.5 decryption in TLS have been a repeated source of Bleichenbacher Oracle attacks, most recently ROBOT: Return Of Bleichenbacher's Oracle Threat. ROBOT also demonstrated how RSA PKCS 1 v1.5 signatures could be rendered using the decryption oracle. By removing RSA Decryption, and switching from v1.5 signatures to PSS signatures, this threat is addressed from both ends.

EdDSA with safer curvers ed25519, ed448 introduced into TLS

A TLS-compliant application MUST support digital signatures with ... and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

TLS 1.3 enables Open/Safer Elliptic Curves

• ECDSA with P-256, P-384 etc from the United States Govemerment has been the security-performance king of TLS 1.2. But, there are concerns raised that many elliptic curves are not well explained and could potentially be backdoored. As such, many are interrested in changing to safer and faster curves.
• EdDSA with curves ed25519, ed448 are now added to TLS. Notably Ed448 has an estimated 224-bit security level, i.e. providing a safe curve with a higher level than the previous US Goverment's NSA Suite B 192-bit security level.

TLS Record encryption

TLS standardize a small set of ciphers that MUST be enabled (i.e. AES GCM) that have been proven over time, and one newer ciper, CACHA20-POLY1305.

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).

Significant focus on modernizing TLS record encryption

The list of supported symmetric encryption algorithms has been pruned of all algorithms that are considered legacy. Those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms.

AEAD cipher modes where the cipher mode is responsible for all of the encryption/authentication concerns are more modern so it makes sense for TLS 1.3 to join this. New AEAD modes, such as ChaCha-Poly1305 and OCB are added to the specification.

Basically TLS1.3 is a lot simpler than TLS 1.2 from this aspect. TLS1.2 covered three different modes of encryption: CBC, Stream Cipher, AEAD. Now, only AEAD remains, no long list of exceptions and variants.

So, time to say goodbye to some old friends and foes from the old specification.

Ciphertext Block Chaning (CBC) mode has been removed

• CBC is a legacy mode which isn't authenticated, leaving most of the cipher security to be implemented by the the protocol designers instead of the cryptographers.
• TLS 1.2 and earlier specified employed a broken authenticate-then-encrypt variant of CBC, that could be decrypted using Oracle attacks (Serge Vaudenay, Lucky13) or decrypted using a browser exploit (BEAST).

Bare stream cipher modes have also been removed. If you want a stream cipher in TLS 1.3, you need to design a AEAD mode for your streamcipher.

TLS 1.3 also asks implementers of TLS 1.3 to clobber the broken RC4 stream cipher from their legacy TLS 1.2 support:

The security of RC4 cipher suites is considered insufficient for the reasons cited in [RFC7465]. Implementations MUST NOT offer or negotiate RC4 cipher suites for any version of TLS for any reason.

Less Round Trip Times

TLS 1.3 takes a significant look at Round Trip Times (RTT), and reduce RTT waiting in both TLS Handshake and RLS Resumption. Over long latency connections (i.e. over the atlantic fiber cables, or worse: over satellite), this should yield noticeable performance gains.

0-RTT Resumption

TLS 0-RTT Zero Round Trip is a major performance bumb to TLS, and also a security trade-off.

Previous TLS versions could resume old connections, reducing the need for slow RSA-handshakes and such, but still imposed an additonal Round Trip Time. This is because the TLS 1.2 resumption basically was:

client                                                    server
    ---> here's client.random and my session id/cookie  --->
    <--- okay, I here you. here's server.random         <---
    ---> TLS RESUMED ENCRYPTED                           -->

TLS 1.3 0-RTT massivly simplifies 0-RTT into:

client                 server
    ---> early data  --->

which removes the round trip time.

This is a significant performance-over-security consideration, as 0-RTT lacks replay protection and is intentionally less secure than previous TLS 1.2 resumption.

Cloudflare, early adopters of TLS/1.3 0-RTT, have written extensively about this in Introducing 0-RTT.

Basically, 0-RTT prioritize protocol efficiency and force application developers (e.g. HTTP/2 server developers) to intelligently drop 0-RTT early data if it isn't a GET stream, or if the GET stream contains query data.

Moving security problems up the stack is often a bad move, but for HTTP speed is king, so moving performance-vs-security decisions out of TLS and up to the application does make sense for its major use-case, HTTPS.

But, 0-RTT replay attacks against bad implementations may very well be a problem in the future.

TLS 1.3 and HTTP/2 both fight to reduce RTT

Considering that HTTP/2 also took efforts to reduce RTT, internet protocols now address performance concerns due to network latency in multiple layers.

Before, HTTPS would need to wait to setup TCP+TLS using 4 RTTs, and then would wait in a slow HTTP/1.1 Request-Wait-Reply fashion, reducing TCP to always waiting one RTT per request. TLS resumption provided some additional speed to set up more connections, but most browsers and servers do not accept that many connections.

Now, HTTPS sets up TCP+TLS using 3 RTTs, and new connections are resumed at 2 RTTs. HTTP/2 removes the Request/Response waiting scheme and allows multiple conurrent streams to be fired off in the same conection, without waiting. Instead of Request-Wait-Reply, HTTP provides Request-Request-Request...-Wait-Reply-Reply-Reply.

So, imagine downloading one thousand small files, with 30ms RTT, downloading could span 30 seconds in just in HTTP network latency wait times. Divide by ten concurrent connections, and we are down to 3 seconds. Now enter HTTP/2 and TLS 1.3, and we theoretically could reduce it to just a few RTTs: TCP handshake RTTs, TLS 1.3 handshake RTTs, post all the requests and wait one RTT.

Test sites such as http://www.http2demo.io/ can be used to show significant performance win for HTTP/2.

So, with TLS 1.3 and HTTP/2, the internet engineers are demonstrating a big commitment to reducing the impact of network latency to system performance and user experience!