1

RFC8446 states that:

the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets

It also states:

length: The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. The length MUST NOT exceed 2^14 + 256 bytes.

This question states the limit simply as 2^14 octets, but that seems to be an oversimplification.

While observing TLS records in Wireshark on my local machine for a particular connection, I noticed that the biggest TLS record sizes never went over 16401 bytes. The observed connection did not use any TLS record length modifying extensions in those largest records.

I went back to reading the RFC to understand how we came to this number in practice, which I wish to run by this community to see if I understand it correctly.

TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets

Here, the 2^14 seems to refer to the plain text that is about to be encrypted and the "+ 1" is reserved for the byte indicating the real future TLS record type. If I add 16 bytes of AEAD to the 2^14 + 1 length of the plain text, I think I get the maximum length of a TLS record without any extensions. 16384 + 1 + 16 = 16401. Which is the number I am seeing in Wireshark as tls.record.length in my largest captured records.

length: The length (in bytes) of the following TLSCiphertext.encrypted_record ... MUST NOT exceed 2^14 + 256 bytes.

This seems to indicate that the maximum TLS record (encrypted, which should already include AEAD) is 16640 octets.

Does that mean that if I encounter largest possible TLS record in Wireshark, with all extension space used up, tls.record.length will never be bigger than 16640 bytes for TLS 1.3 connections?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
miran80
  • 123
  • 4
  • 1
    Do please use the code designation for code only. Although RFC's are using monospaced fonts and a consistent number of columns that doesn't make it code. I personally don't think there is too much to be cleared up. The max plaintext size and max ciphertext size are clearly stated and of course they are linked, with the ciphertext size clearly dependent on the cipher used, with the cipher suites possibly extended in followup RFC's. What part are you uncertain of? – Maarten Bodewes Mar 30 '24 at 16:00
  • @MaartenBodewes Does that mean that if I encounter largest possible TLS record in Wireshark, with all extension space used up, tls.record.length will never be bigger than 16640 bytes for TLS 1.3 connections? – miran80 Mar 30 '24 at 16:26
  • 2
    Yes, but be aware that there have been issues with WireShark in the past, and obviously a non-compliant implementation can still muck things up. Also beware the 5 byte plaintext overhead. Usually of course it will be smaller than this, depending on the cipher suite used. The currently listed AEAD ciphers have a similar overhead though. When you are implementing this and e.g. streaming the bytes into a buffer then you can simply stop the connection when 2^14 + 256 has been reached, limiting the buffer regardless of the cipher suite. – Maarten Bodewes Mar 30 '24 at 16:47
  • 2
    Fun note: there is a current IETF draft draft-mattsson-tls-super-jumbo-record-limit that would allow (assuming both sides agree) larger record sizes. It is currently unclear if this will actually be adopted. However, if the reason you're asking is because you're working with a middle box and need to know the maximum record size it needs to handle, the current limits might not hold... – poncho Mar 30 '24 at 17:09
  • Hmm, a middle box that is protocol aware but doesn't decrypt for obvious reasons. Uh, I guess you can share connection details and session keys with the box. I'm more familiar with firewalls etc. that replace the entire server authentication through replacing the PKIX (and trusting the required certificate for that through group policy). That kind of solution could just refrain from not allowing larger record sizes. – Maarten Bodewes Mar 30 '24 at 17:34
  • @MaartenBodewes: if you have an active middle box (that is, one that negotiates with both sides, and decrypts/reencrypts records that it receives), it could use RFC 8449 to set any record size limit it finds convenient. – poncho Mar 30 '24 at 17:46
  • @poncho I don't think this is possible with how TLS 1.3 handles encryption. – miran80 Mar 31 '24 at 06:57
  • @miran80: Which of my statements are you questioning? If you were referring to draft-mattson-tls-sub-jumbo-record-limit, well, if you have concrete reason to believe it wouldn't work, you should mention that on the TLS mailing list. If you're referring to my suggestion that an active middle box could take advantage of RFC 8449, well I don't understand your objection. – poncho Mar 31 '24 at 11:41
  • @miran80: or are you questioning the existence of 'active middle boxes'? I (and Maarten) know for a fact they do exist - they work by having the client contain a CA root that is owned by the middle box (and having the middle box construct the appropriate certificate on the fly as needed when it negotiates with the client). – poncho Mar 31 '24 at 11:59

0 Answers0