The DTLS 1.3 standard has recently been published in April 2022 in RFC 9147. It features many improvements and additions to increase security and efficiency of the DTLS protocol. At wolfSSL, we like to be very quick adopters of new standards which is why initial support for DTLS 1.3 was merged in June and appeared in wolfSSL release 5.4.0. In this blog post we will go through the list of changes from DTLS 1.2 described in sections 12 and 13 of RFC 9147 and expand on what they mean for your security.
Another exciting feature of DTLS 1.3 is post quantum cryptography! It is available in wolfSSL using the same interface as for TLS 1.3. See this blog post for more details.
- New handshake pattern, which leads to a shorter message exchange.
In TLS 1.3, the handshake protocol has been simplified to 1 round trip from the previous 2 round trips. DTLS 1.2 and 1.3 both add an extra round trip for the stateless cookie exchange.
Old DTLS 1.2 handshake
Client Server ------ ------ ClientHello --------> Flight 1 <------- HelloVerifyRequest Flight 2 ClientHello --------> Flight 3 ServerHello \ Certificate* \ ServerKeyExchange* Flight 4 CertificateRequest* / <-------- ServerHelloDone / Certificate* \ ClientKeyExchange \ CertificateVerify* Flight 5 [ChangeCipherSpec] / Finished --------> / [ChangeCipherSpec] \ Flight 6 <-------- Finished /
New DTLS 1.3 handshake
Client Server +--------+ ClientHello | Flight | --------> +--------+ +--------+ <-------- HelloRetryRequest | Flight | + cookie +--------+ +--------+ ClientHello | Flight | + cookie --------> +--------+ ServerHello {EncryptedExtensions} +--------+ {CertificateRequest*} | Flight | {Certificate*} +--------+ {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} +--------+ {CertificateVerify*} | Flight | {Finished} --------> +--------+ [Application Data] +--------+ <-------- [ACK] | Flight | [Application Data*] +--------+
- Only AEAD ciphers are supported. Additional data calculation has been simplified.
AEAD ciphers provide a unified encryption and authentication operation. Before (D)TLS 1.3, authentication would be accomplished using a technique called MAC-then-Encrypt. This would use an HMAC to compute an authenticated code of the data and then encrypt the concatenation of the plaintext and the code into ciphertext. The recipient can check the authenticity of the data by computing the HMAC code and comparing with the one received. AEAD ciphers simplify this into one operation.
- Removed support for weaker and older cryptographic algorithms.
All legacy ciphersuites have been removed and are no longer valid with DTLS 1.3. This improves security by only allowing peers to communicate using strong ciphersuites.
- HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.
The HelloRetryRequest replaces the DTLS 1.2 HelloVerifyRequest. This allows peers to negotiate security parameters and perform a cookie exchange at the same time.
- More flexible cipher suite negotiation.
Ciphersuite negotiation has been separated into different extensions. Previous versions of (D)TLS had included all possible permutations of symmetric and asymmetric ciphers in the ciphersuite list. In (D)TLS 1.3 the ciphersuites only contain the AEAD and hash algorithms that will be used for the connection. Other security parameters are negotiated in extensions like supported_groups, signature_algorithms, key_share, or pre_shared_key.
- New session resumption mechanism. PSK authentication redefined.
In (D)TLS 1.3, session resumption and PSK have been combined into one mechanism. To resume a session, the server sends NewSessionTicket messages to the client containing tickets that can be used in subsequent connections. "session IDs" and "session tickets" are now obsolete.
Additionally, when resuming a session, the client can immediately send “early data” in its first flight of the handshake. This is also called 0-RTT Data since it allows peers to exchange data in the first round trip. This is useful to drastically cut down on the latency of a new connection and speed up the initial round of communication between the peers.
- New key derivation hierarchy utilizing a new key derivation construct.
TLS 1.3 has introduced a new key schedule for deriving secrets using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) primitive. This separates the multiple secrets used in the TLS connection. See this section for the specifics.
- Improved version negotiation.
Version negotiation no longer uses the value found in the Record header. Now an extension is used to advertise all supported (D)TLS versions. This new mechanism is to overcome some middleboxes failing when presented with a new (D)TLS version value.
- Optimized record layer encoding and thereby its size. Sequence numbers are encrypted.
DTLS 1.3 introduces a very efficient “unified header”. This new header format also obfuscates the epoch and sequence numbers to make traffic analysis harder.
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|1|C|S|L|E E| +-+-+-+-+-+-+-+-+ | Connection ID | Legend: | (if any, | / length as / C - Connection ID (CID) present | negotiated) | S - Sequence number length +-+-+-+-+-+-+-+-+ L - Length present | 8 or 16 bit | E - Epoch |Sequence Number| +-+-+-+-+-+-+-+-+ | 16 bit Length | | (if present) | +-+-+-+-+-+-+-+-+
Figure 3: DTLS 1.3 Unified Header
- Added CID functionality.
RFC 9146 has introduced connection identifiers in DTLS 1.2. A similar mechanism is defined in DTLS 1.3. Users of CID’s can mark packets so that they are multiplexed according to the CID instead of the IP 4-tuple allowing records to be sent through multiple paths at once!
Contact us at facts@wolfssl.com with any questions regarding DTLS 1.3.