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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 20, 2025 at 8:07 PM Martin Thomson <[e-mail]> wrote:

> This seems OK to me.
>
> The document doesn't really say what "invalid" means for the length
> encoding.  Does that mean the record is ignored, or does the connection
> break?  I think that the answer is the former for DTLS, the latter for
> TLS.  (Allowing the connection to break was probably a mistake in RFC 8449,
> but I think that was because of the possibility of layering on SCTP or
> other reliable medium.)  It might be worth saying that receiving a record
> length that starts with 0b11 should be treated as though the record were
> over-sized.  Error handling for that is well-specified.
>

I concur with MT that malformed length encodings should not cause
connection termination in DTLS.

-Ekr


> I would not worry about the size adjustments in the AEAD limits.  Those
> 256 bytes don't change things at all and I think that the limits apply to
> plaintext sizes anyway (which can be up to 2^14.
>
> Typo: AES-CGM
>
> On Wed, Nov 5, 2025, at 01:55, Sean Turner via Datatracker 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]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>