Thread by @ic0nz1

Now that DTLS 1.3 is out, here is my personal TLDR 🧵

DTLS 1.3 is mostly TLS 1.3, with changes to make it more DTLS like. Most bad crypto gone, good crypto left.

The version and type field of encrypted records are gone. They did not have a purpose in TLS 1.3 other than not breaking deployed buggy network equipment.

On the wire Epochs (for epoch >=1) and SQN's are shorter. For cryptographic computations, 2 64bit values are used.

The length field of DTLS ciphertexts is now a variable-length field. This is interesting, as since SSLv2 all length fields in the TLS protocol were constant length.

Effectively this is a tradeoff between complexity and saving a byte on the wire. This is in sync with the current trend to move to more space-efficient encodings (cTLS, QUIC,...).

The length field of encrypted records can now even be missing entirely (by using bit encodings in the first byte of the header), resulting in a 2-byte header (!). 2 Bit for the epoch, 8 bit for the SQN.

In older TLS and DTLS protocols, encoding information with bitmasks was uncommon. I do not really like the newly added complexity, but it's definitely more efficient...

Encrypted DTLS records can now contain a (plaintext) connection ID (RFC9146) that can be used to identify the connection a record belongs to. This is useful if you are doing NAT rebinding.

Record sequence numbers of encrypted records are now encrypted as well. DTLS 1.3 does this by computing a 'mask' by encrypting the first 16 bytes of the ciphertext (again) with the primary encryption algorithm in ECB mode (e.g if you are using AES-GCM you are using AES-ECB).

In the case of Chacha20, the mask is generated by using the first 4 bytes of the ciphertext as a block counter and the next 12 bytes as the IV.

The key for these ciphers is an individual key derived from the current secret with the HKDF function. The 'mask' is then XOR'ed onto the wire representation of the SQN to encrypt/mask it.

Interestingly, this means that the ciphertext has to be at least 16 bytes, this is usually the case since the auth. tags are usually 16 bytes long anyways, but in some cases (CCM8), the optional padding of DTLS is not so optional anymore if really short messages are transmitted.

Implementations need to count failed decryptions now. The limit of failed decryptions is defined by the AEAD that is used.

DTLS does not use the compatibility mode of TLS 1.3. No more fake CCS messages, no more session resumption theater. Nice!

The DTLS cookie is now transmitted in the Cookie extension of an HRR. The cookie field in the CH is deprecated (but still present).

In contrast to DTLS 1.2, the cookie exchange is now also part of the handshake transcript; the server, therefore, has to place the hashes of the cookie exchange message in the cookie to be stateless.

The message sqn fragment_offset and fragment length values are no longer part of the transcript. In previous versions, one had to reassemble fragmented messages and add them to the transcript as if they were sent in one piece.

The EndOfEarlyData message is gone as DTLS already has epochs to distinguish the used keys.

The document contains more details on how the message processing should be done. I am curious if we will see these details in actual implementations. *doubt it*

DTLS 1.3 uses the label prefix "dtls13" instead of "tls13 " - note the missing space to make the labels the same length, ensuring that the computations do not require an additional iteration of the hash function.

There are new messages: The ACK message. It is implemented as its own protocol (26) and allows peers to indicate which records they have received. I like it.

The 'NewConnectionId' message can be used to update connection identifiers.

There is also an official TLDR at the end of the document (which I didn't find until after i wrote my own). 😅

I am curious if DTLS 1.3 will get a lot of traction as it competes with QUIC. The overall changes seem reasonable, but the overall complexity of the protocol has increased again, making it harder and harder to implement.