This document looks basically good. I have some comments below. I believe at least the first comments hould be addressed before this document advances.
S 3. The large record size limit only applies to records sent toward the endpoint that advertises the limit. An endpoint can send records that are larger than the limit it advertises as its own limit. A TLS endpoint that receives a record larger than its advertised limit MUST generate a fatal "record_overflow" alert; a DTLS endpoint that receives a record larger than its advertised limit MAY either generate a fatal "record_overflow" alert or discard the record. Is there a reason to allow a DTLS endpoint to generate an alert in this case? This seems like it creates an easy DoS attack on the connection. At least, I think we should recommend it discard the record. Unprotected messages and records protected with early_traffic_secret or handshake_traffic_secret are not subject to the large record size limit. I think this wants to say "are subject to the usual record limit", correct? They're not unlimited. The "large_record_size_limit" extension is not compatible with middleboxes expecting TLS 1.2 records and SHOULD NOT be negotiated where such middleboxes are expected. A server MUST NOT send extension responses to more than one of "large_record_size_limit", "record_size_limit", and "max_fragment_length". A client MUST treat receipt of more than one of "large_record_size_limit", "record_size_limit", and "max_fragment_length" as a fatal error, and it SHOULD generate an "illegal_parameter" alert. Do we want to provide some guidance for which one to use? S 4. TLS 1.3 [RFC8446bis] and DTLS 1.3 [RFC9147] limits the number of full-size records that may be encrypted under a given set of keys. Increasing the maximum record size to more than 2^14 + 256 bytes while keeping the same confidentiality and integrity advantage per write key therefore requires lower AEAD limits. When the "large_record_size" has been negotiated record size limit larger than Nit: "negotiated with a record size limit" On Mon, Nov 24, 2025 at 6:21 AM Sean Turner <[email protected]> wrote: > A final reminder that this WGLC ends tomorrow. > > spt > > > On Nov 20, 2025, at 11:00, Sean Turner <[email protected]> wrote: > > > > Another reminder that this is still on-going. > > > > spt > > > >> On Nov 13, 2025, at 19:25, Sean Turner <[email protected]> wrote: > >> > >> Just a reminder that this is still on-going. > >> > >> spt > >> > >>> On Nov 4, 2025, at 23:55, Sean Turner via Datatracker < > [email protected]> wrote: > >>> > >>> > >>> Subject: WG Last Call: draft-ietf-tls-super-jumbo-record-limit-02 (Ends > >>> 2025-11-25) > >>> > >>> This message starts a 3-week WG Last Call for this document. > >>> > >>> Abstract: > >>> TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to > >>> 2^14 + 1 bytes, which includes one byte for the content type. > >>> Records also have a 3-byte overhead due to the fixed opaque_type and > >>> legacy_record_version fields. This document defines a TLS extension > >>> that allows endpoints to negotiate a larger maximum inner plaintext > >>> size, up to 2^30 - 256 bytes, while reducing overhead. > >>> > >>> File can be retrieved from: > >>> > https://datatracker.ietf.org/doc/draft-ietf-tls-super-jumbo-record-limit/ > >>> > >>> Please review and indicate your support or objection to proceed with > the > >>> publication of this document by replying to this email keeping > [email protected] > >>> in copy. Objections should be motivated and suggestions to resolve > them are > >>> highly appreciated. > >>> > >>> Authors, and WG participants in general, are reminded again of the > >>> Intellectual Property Rights (IPR) disclosure obligations described in > BCP 79 > >>> [1]. Appropriate IPR disclosures required for full conformance with the > >>> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are > aware of > >>> any. Sanctions available for application to violators of IETF IPR > Policy can > >>> be found at [3]. > >>> > >>> Thank you. > >>> > >>> [1] https://datatracker.ietf.org/doc/bcp78/ > >>> [2] https://datatracker.ietf.org/doc/bcp79/ > >>> [3] https://datatracker.ietf.org/doc/rfc6701/ > >>> > >>> > >>> > >> > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
