RFC 8446: Transport Layer Security 1.3

2019-09-11 tls web

Transport Layer Security 1.3 (RFC 8446)

1. Major differences from TLS 1.2

  • All legacy algorithms have been deprecated. TLS 1.3 uses AEAD instead.
  • 0-RTT (zero round-trip time) mode was added.
  • All public-key based key exchange mechanisms now provide forward secrecy.
  • Simplified the handshake state machine (removed ChangeCipherSpec in most common cases).
  • Cryptographic improvements.
    • KDF: HMAC-based KDF
    • RSA padding
    • DSA removed
    • Ephemeral Diffie-Hellman removed
  • Session resumption has beed replaced by a simple PSK exchange

AEAD: Authenticated Encryption with Associated Data

2. Protocal Overview

Handshake Protocal and Record Protocal


Basic Key Exchange Modes:

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

Session Resumption in TLS 1.3

Session ID used in TLS 1.2 has been obsoleted.

PSK: a PSK identity that corresponds to a unique key derived from the initial handshake.

In TLS 1.3:

  • PSKs are used in ECDHE (with FS)
  • PSKs are used alone (without FS)

0-RTT mode


The security properties for 0-RTT data are weaker than those for other kinds of TLS data.

  1. no gurantees of forward security: used PSKs only
  2. no guarantees of non-replay

3. HandShake Protocal

No renegotiation in TLS 1.3

Three basic functions:

  1. Key Exchange Messages
  2. Server Parameters Messages
  3. Authentication

Client Hello: either a set of Diffie-Hellman key shares (in the “key_share” (Section 4.2.8) extension), a set of pre-shared key labels (in the “pre_shared_key” (Section 4.2.11) extension), or both;

Incorrect DHE Share

the server corrects the mismatch with a HelloRetryRequest and the client needs to restart the handshake with an appropriate “key_share” extension


4. Record Protocal

Four types: handshake, application_data, alert, and change_cipher_spec.

change_cipher_spec is used only for compatibility purposes

Record Protocal may be encrypted by AEAD algorithms.( application_data)

5. 0-RTT and Anti-Replay

In order to defense the replay attack in 0-RTT, there are two baisc requirements:

  1. The server MUST ensure that any instance of it would accept 0-RTT for the same 0-RTT handshake at most once;
  2. Applications must anti-replay

How to do?

  1. Single-Use Tickets
  2. Client Hello Recording
  3. Freshness Checks