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