1
$\begingroup$

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?

Improve this question
$\endgroup$
9
  • 1
    $\begingroup$ 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? $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 30 at 16:00
  • $\begingroup$ @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? $\endgroup$
    – miran80
    Commented Mar 30 at 16:26
  • 2
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 30 at 16:47
  • 2
    $\begingroup$ 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... $\endgroup$
    – poncho
    Commented Mar 30 at 17:09
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 30 at 17:34

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.