Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt

[John Mattsson <[e-mail]>]

Thanks Ben,

>I confess that my first impression was "eww, extensions with side effects on
>other extensions, that sounds super finicky to implement correctly".
>
>But actually reading in further, it seems more that the guiding principle is
>instead "only have one way to do a thing", in this case to communicate
>the maximum record size an endpoint is prepared to receive.
>That said, it's still changing the semantics of an existing field, which
>incurs a requirement to survey the compatibility with existing
>implementations.  I see that RFC 8449 does carve out a way for endpoints
>to send larger values if "explicitly allowed by such a future version or
>extension.  A server MUST NOT enforce this restriction" so in theory we
>should be okay, but we still need to actually check.

That is indeed a good thing to check and discuss. The alternative is of course to define a new extension instead.

>I also note that the semantics of record_size_limit per RFC 8449 are to
>apply to the plaintext length, so I think it actually is weird and
>overly complicated for your draft to propose that the negotiated length
>will now be of the ciphertext length.

Thanks for spotting this. That is just a mistake caused by the extension in the -00 version of the draft having the meaning “I am prepared records with ciphertexts of length 2^16 - 1”. If RFC 8449 is used, the semantics should not be changed. We will fix this in the next version.

Cheers,
John Preuß Mattsson

From: Benjamin Kaduk <bkaduk=[e-mail]>
Date: Friday, 1 March 2024 at 20:42
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt
Hi John,

I confess that my first impression was "eww, extensions with side effects on
other extensions, that sounds super finicky to implement correctly".

But actually reading in further, it seems more that the guiding principle is
instead "only have one way to do a thing", in this case to communicate
the maximum record size an endpoint is prepared to receive.
That said, it's still changing the semantics of an existing field, which
incurs a requirement to survey the compatibility with existing
implementations.  I see that RFC 8449 does carve out a way for endpoints
to send larger values if "explicitly allowed by such a future version or
extension.  A server MUST NOT enforce this restriction" so in theory we
should be okay, but we still need to actually check.

I also note that the semantics of record_size_limit per RFC 8449 are to
apply to the plaintext length, so I think it actually is weird and
overly complicated for your draft to propose that the negotiated length
will now be of the ciphertext length.

-Ben

On Mon, Feb 26, 2024 at 08:59:20AM +0000, John Mattsson wrote:
>    Hi,
>
>
>
>    We just submitted version -01 of “Large Record Sizes for TLS and DTLS”.
>    Michael Tüxen is a new co-author, the extension has been renamed to the
>    more mundane “large_record_size" and is now a flag extension. The flag
>    extension is now used together with "record_size_limit" to allow
>    negotiation of maximum record size, not just a fixed 2^16 – 1 bytes.
>
>
>
>    The use for record sizes larger than 2^14 has been discussed in TSVWG for
>    use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be
>    beneficial in several of the discussed solutions to remove limitation or
>    to increase performance.
>
>
>
>    We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in
>    Brisbane.
>
>
>
>    Cheers,
>
>    John Preuß Mattsson
>
>
>
>    From: [e-mail] <[e-mail]>
>    Date: Monday, 26 February 2024 at 09:34
>    To: John Mattsson <[e-mail]>, Michael Tüxen
>    <[e-mail]>, Hannes Tschofenig <[e-mail]>,
>    Hannes Tschofenig <[e-mail]>, John Mattsson
>    <[e-mail]>, Michael Tuexen <[e-mail]>
>    Subject: New Version Notification for
>    draft-mattsson-tls-super-jumbo-record-limit-01.txt
>
>    A new version of Internet-Draft
>    draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully
>    submitted by John Preuß Mattsson and posted to the
>    IETF repository.
>
>    Name:     draft-mattsson-tls-super-jumbo-record-limit
>    Revision: 01
>    Title:    Large Record Sizes for TLS and DTLS
>    Date:     2024-02-26
>    Group:    Individual Submission
>    Pages:    6
>    URL:
>    [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt
>    Status:
>    [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
>    HTML:
>    [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html
>    HTMLized:
>    [4]https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
>    Diff:
>    [5]https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01
>
>    Abstract:
>
>       RFC 8449 defines a record size limit extension for TLS and DTLS
>       allowing endpoints to negotiate a record size limit smaller than the
>       protocol-defined maximum record size, which is around 2^14 bytes.
>       This document specifies a TLS flag extension to be used in
>       combination with the record size limit extension allowing endpoints
>       to use a record size limit larger than the protocol-defined maximum
>       record size, but not more than about 2^16 bytes.
>
>    The IETF Secretariat
>
> Links:
> 1. https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5PQtjvw8A$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5PQtjvw8A$>
> 2. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5MOtgMACw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5MOtgMACw$>
> 3. https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5NSq7RMpA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5NSq7RMpA$>
> 4. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O0NTWNIQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O0NTWNIQ$>
> 5. https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5Phx4rvmg$<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5Phx4rvmg$>

> _______________________________________________
> TLS mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O_FNpPMw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O_FNpPMw$>