[TLS] Re: WG Last Call: draft-ietf-tls-super-jumbo-record-limit-02 (Ends 2025-11-25)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

> A final reminder that this WGLC ends tomorrow.
>
> spt
>
> > On Nov 20, 2025, at 11:00, Sean Turner <[e-mail]> wrote:
> >
> > Another reminder that this is still on-going.
> >
> > spt
> >
> >> On Nov 13, 2025, at 19:25, Sean Turner <[e-mail]> wrote:
> >>
> >> Just a reminder that this is still on-going.
> >>
> >> spt
> >>
> >>> On Nov 4, 2025, at 23:55, Sean Turner via Datatracker <
> [e-mail]> 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
> [e-mail]
> >>> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>