I went to look a bit more deeply at the interaction between RFC 8449 and this new limit and I'm wondering; is there a good reason to permit values lower than 2^14? this is named "Large" and "Jumbo" after all. One reason I ask is that with this restriction a client can cache the limit if it's 2^14 or below and that's that. The logic of whether to apply the limit to the handshake and early data becomes unambiguous from that cached value. Otherwise, because the values can overlap, additional client-side state is needed because the mechanisms differ in how handshake and early data should be sent.
Separately, the draft references the AEAD limit calculations in RFC8446 - but there are no AEAD limit calculations in RFC8446. Section 5.5 does have a reference, but the link is now broken. This is particularly unhelpful for ChaCha20/Poly. Will the record sequence number still wrap before doom? The answer can't be pieced together from the documents. Even if you do find the new link, the analysis assumes 2^14 sized records; it's not a variable in the calculations or tables, so the reference doesn't help. The text in the draft now says ... ``When the "large_record_size" has been negotiated record size limit larger than 2^14 + 1 bytes, existing AEAD limits SHALL be decreased by a factor of (LargeRecordSizeLimit) / (2^14-256).'' what does that mean? Is the AEAD limit supposed to be on the number of messages (records in TLS speak) encrypted? or is it on the amount of data actually sent? or some combination of both? The former alone is pretty punitive. That's only 262k records at a 2^32 sized record limit. That's not great for a protocol such as NFS, where I might reasonably want to transfer a large file as a very very big record, but most of the other records are small and chatty, and at the same time I want a session that can last years rather than run out records so quickly. In that case, I'd much prefer to track how much data is actually sent and derive the safe AEAD limit from that; but the calculation isn't so simple. On Wed, Jul 16, 2025 at 4:53 PM Benjamin Kaduk <bkaduk= [email protected]> wrote: > On Wed, Jul 16, 2025 at 01:10:32PM -0700, Eric Rescorla wrote: > > This Message Is From an External Sender > > This message came from outside your organization. > > > > I have one editorial comment and one technical comment on this draft. > > The limit here is defined as: > > LargeRecordSizeLimit denotes the maximum size, in bytes, of inner > > plaintexts that the endpoint is willing to receive. It includes > the > > content type and padding (i.e., the complete length of > > TLSInnerPlaintext). AEAD expansion is not included. > > > > I believe that this is the same value as RFC 8449: > > > > This value is the length of the plaintext of a protected record. > The > > value includes the content type and padding added in TLS 1.3 (that > > is, the complete length of TLSInnerPlaintext). In TLS 1.2 and > > earlier, the limit covers all input to compression and encryption > > (that is, the data that ultimately produces > TLSCiphertext.fragment). > > Padding added as part of encryption, such as that added by a block > > cipher, is not included in this count (see Section 4.1). > > > > IMO it would be good to explicitly state that these are the same > > value, so people don't have to decode it. > > I agree that it is a good idea to be explicit that the intent is to be > aligned > here. It seems that in the individual draft the limit applied to the > ciphertext length and I noted [1] that the RFC 8449 record_size_limit > semantics > were on the plaintext. John's response [2] confirms that the semantics > should > not be changed from RFC 8449. > > -Ben > > [1] https://mailarchive.ietf.org/arch/msg/tls/fzzeBLS3Cm9mnivAU2NOUP-juoU/ > [2] https://mailarchive.ietf.org/arch/msg/tls/XvHqp4atYv2cyhijdDDefBChVTo/ > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Colm
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
