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

[Valery Smyslov <[e-mail]>]

Hi,

I read the document and I support its publication.

I think that the text of the document can be a bit more accurate with the use of word "negotiate".
While the extension itself is "negotiated", the record size is independently "announced" (or "advertised")
by each side to its peer, so the limits can be different in different directions (which is explicitly stated in the draft).
But the text uses the form "negotiate a larger maximum inner plaintext size" several times, which to 
my (non-native) ear sounds like "a single value for both directions is negotiated", which is wrong.

For the following requirement: 

    "When decoding, any value that uses more bits than necessary MUST be treated as malformed."

I don't see a good justification. Perhaps some reasoning can be given in the text
(I assume that the packet can be correctly decrypted and its authentication tag is valid).
In addition, it is not clear what "treated as malformed" means. Should the packet be dropped
(looks like this is implied, but see above)? Should in addition the connection be closed?

It is not clear from the draft what to do with packets with invalid encoding (11 in the two higher bits).
Obviously, these packets must be discarded, the question is what to do with the connection - 
should it be closed (as with receiving invalid packets in TLS) or not (as with ignoring
invalid packets in ESP). I can imagine that it should be closed in case of TLS and
persist in case of DTLS, but this is not spelled out in the draft (or I missed it).

Regards,
Valery.

> 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]