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 -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
