Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS

John Mattsson <john.mattsson@ericsson.com> Wed, 20 March 2024 04:33 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB0C15108E for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 21:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.008
X-Spam-Level:
X-Spam-Status: No, score=-7.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BivndZ2hVAlx for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 21:33:21 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2138.outbound.protection.outlook.com [40.107.20.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E8C151084 for <tls@ietf.org>; Tue, 19 Mar 2024 21:33:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZVJh6NDPhls+geRaLbvFlXq7ZWxzlLjycGVM+G0lz2q5thkVzjqrj2upnppz+m9uDFyR16UT937Nx3W32y7yNXlcyqvnEv3wVqcTSFZ3Cbrgj3l5t7MctoYDuZkS3gBnXhqMMEAc9c/3D86xVTsi5/APtV+SOHFW8T6rEnx4YqOhI0yF204GPzFCYFgAmYtXH0cyqz5vmgWtckSm8kJd9yrphoGF9dWYBt99uBCL8cpswP00PHDCpUjagsIpLLpH2E3fJ7e9D6fhp8rOg0oDm16cdn9StpipFgCcWFcFJeJoaYy/MedHlnNuYMYe7LyBXBaFjA1d8ArlQL2On8Gdmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zmqJ3YPOXZODQlk+YTdsuEVcRLmN7bwRmKrx6E3Ywgs=; b=DXGVWKC7gbP0mANcD/MIgHaF6vDDTKRoqmskgwVsbA+EgfbULZfFM22MF/Kyu2cN9ezimTlfcwxo+DOqQp5St/Tcdwrzcq/fRhLu477jgZ5ZQnN7nvc8Tc8L19Kimw3kNwIGfRfioeDseBVaiKbS4ucjBfb5K+Ws6FVRiDFEgxZhrp73jt2p//xxfKar25DYmUMybAlykejH+Od8xzla0Etr3r37Efp2wEojBU8YMo8a2az8t5xi/W0g1rQSs5o6/k9oGF6vyNjXm2IIS4dZaZm2qVTHNCA1CbBzsHOzohxtaYfEQ14eWBVgo0yuQxQgqom3sxcaqry1KA9GoFFwgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zmqJ3YPOXZODQlk+YTdsuEVcRLmN7bwRmKrx6E3Ywgs=; b=O86kTUth34NqR3W1+7y6oW4iaPmDQLckH/+rWYPrrZQ8p7Erl2h9dhUrqmJFBpNy9JXiIlOc3javDf/jg02m81lREDQia5PzmiSrvNUMfw6Vd2L73v5aQs3q2B2+/uMUSk3Jf4x/l+tEj7sVGTEUz+gnzNZjPz+Kv/OK6fzoLAoFaaborZY3oRj/7TrymIxqpqGvZy1mlK8IZ4MZ6owee4KR/EXkIbmwjtQ4I9Mu7ZAlTeXt3bNWsj8KynKkt4OEPSIca1bZHuxsnBuzazq9e5k4sKxhCQpWEDdZ3o/h5aS8Rf9DBvZRH7Fe0ABEdrIqbZijvRIAvysl520oD9ptnA==
Received: from GVXPR07MB9678.eurprd07.prod.outlook.com (2603:10a6:150:114::10) by PAXPR07MB8388.eurprd07.prod.outlook.com (2603:10a6:102:22a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Wed, 20 Mar 2024 04:33:16 +0000
Received: from GVXPR07MB9678.eurprd07.prod.outlook.com ([fe80::b0d0:9785:585a:9568]) by GVXPR07MB9678.eurprd07.prod.outlook.com ([fe80::b0d0:9785:585a:9568%4]) with mapi id 15.20.7386.025; Wed, 20 Mar 2024 04:33:16 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Next steps for Large Record Sizes for TLS and DTLS
Thread-Index: AQHaeniaeD/NGo8+rkCQgpGaGlBR+LE//XCAgAAM2Oo=
Date: Wed, 20 Mar 2024 04:33:16 +0000
Message-ID: <GVXPR07MB9678CA51D390749E905BC7C389332@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: <170958339152.58675.742327505310055736@ietfa.amsl.com> <GVXPR07MB967894D717FD064E9690CC4A89332@GVXPR07MB9678.eurprd07.prod.outlook.com> <2099ebf2-f56f-47c7-9846-515bca19e299@app.fastmail.com>
In-Reply-To: <2099ebf2-f56f-47c7-9846-515bca19e299@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GVXPR07MB9678:EE_|PAXPR07MB8388:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7aTk6c5qaAHzo/A5cmHPSPccwN2sKE9iSsx/SGHjKfaHjcMWx1Ukbz5oFY6S0kwDz/VhDjcKIt5O08SKPPf3mavN33SOwdJR0qj7iLnV1SBDysVzaDXNEMmbGO+v1zQJWllGzsWa83aFSNR6W2k0pL3V3qGPnfIe8mjTYfddlvbO8aTsxolpHutmt7Vy0KaPF71hKZCjHLrV08dM1IbONvV69mlhqr9M5vjjfWVnFatXzua7GdyhhnTnPXwf6xI8rjo8sDKpW42tLkuS98KzgexgG/cQiohh+zL0uttalxBpIKaMXiCzqd9aSS/36oamobM9ShNXEfHPB/2YMQdTtBrjXO0DheqhbArddYvvRt93SbzIDnW6MNG1PmfV1FhUvxo5xiJzEJfD472ydXCuXq0H4yjG89gTVG23depY0If7vfyEEHkSAcgJYPWIxW3f5RA6x9GFEbRZrl9vIA51kuGuHa3cxmRA5ltILV+cNGBPG3Qlx+1yeqwbZMX+HDeu5pWyIRnTztourcEDv8CaC8dfg4Wlw7x5On2y3AuEfW9Vcy7GNpzlUw64YTWZubB1NWv0zJz0DLWkvePCTxEKmr+gJ+vEDgumIcYM2OHgpKc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:GVXPR07MB9678.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(1800799015)(376005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: p7U6z8tYUjst/7lJhFXVBlmyZFdB/GUneZcpHq8JoWtLgUE/kRNIwtq+51cCb9sGCeGXU9FgO6bhu6HLlVItP4EThu+2X6R/beC5uUTKCYJXtyhg2IWhV55tdDtUot7Yp3SqRfkA0D5L8rvNnm+yRzqZpE3NVkiRrkMv2nfuEel5idQShi2xgFFLfyIwK1DdsA47ZA4mRkzW2Y1zhnNnXyI7XBLxmwhoyXRqNnRj3XvaIJKqtpuLZtaDMaVIRpYP7WL9DnKYvhGxgYAVnCbYltNsAIEOhYTcUftC88feugCR7FhqIsF2NGSuOhUFEIqWai+ebm4z2yVBry5MUECyFs7r87OvkJfD60Sfi3Nf9qYkks0QwEHubO4rzwHOVCsU97DQQ8GiJgWb8K94sPrXqaKqSyQWCwWHLEmIbj7nlvzghAOV8PK+I9nzukD0lhAvkk41pvAt5ktXQs+r15vDyQP9bHosrQEyylPUR4ny4vVWA9/YvtDVeUypJ31Juk2vcbWb8d2u2KlZ9EpJgERm+EfaHQm4a1ZrPXyGRQ3uLUJ6PqFJEptokDMMiHRFl7vdZxtUoe9NSFbHZGyGlslDfPcEuYlw91KsskTu/VvirgU8S3e6NfS27lj4i3surT3e5Rwv1735FxZ9mi3KsyexaLGnD9wXKRlp8khOl1xXg+RIfcYn5FDWHAXlTrw9sCWvMQ3hBsyD2M+K+lOgyLxTjfB1vIndfGRUN66OwivQDX0pahlRBy0wt6i3Nt1a3H5F7gDCQ+lc9LKzM+2b51okBX2MQn8hDs3+cXChtwP5y82jlhnUGBupBEMgC0VKZTtK4Quo0KZTRnHoEy1ku9uNzOE6apsnDEveT/Z7MLrHIexaWSnUBqyPInh4J3pGjY9NutrQY4QEpCg9qvVFyoNvabxUlSyEY8Th0CgUzTkH+OA9VmwSvlfbBUjSvNHznIX762DqwK9HezDN959A8g6lpO128EaL8s1RUcDzOGPRZwcK0IzExFyJ+86BK7mF5yCFIGF8YfivupeNBP3QzK/6FIrEQQU6YQ3Xoo3xsmXxz2xDhW7fJAVdeGh2MFzGBXFblafcNU6Zi9Cva3CGgQNQ/eXqZp8aTPMVUT71McgbgzsRqqEZSbz6n1ai/8Vpkk8otgVsQ+AppR/B0YXBF/Y639VBK+LHVkUYL/uzHAvN0pPu7sGKQRRGKhAKoG1hx1/Frw4uG7WyFP3vnBDmnFovnMOpmrwlwKEPxT6tNeFNCV7Oh1BTmYiZT0Q0BkVt0uDOsHJaWynBEiVQw3WkcjCcAqczoEqRQFXMYGM9wUIuExAJod5dXkloSyuMi1x75ltiyCnJgfhAGYmLioDeqknVMhEdEHgOBBsFfnNU7+HATMIzhknNH+qQfFnvsEJjRm255MNmvn04s5+hX9zK2ZEWxfs6EtMh4u8iQEstxtbzp33jyK93Z4Fn7BY7KSJ9NbytmXS6qBihsGW8lcsT/QvNZ8SAap8X2VNpmGbSfycuRgyAEBqgDg3C3OxBcDFxZcLsk1txzyIGQmjAgdjQ38BHHAhV7PGCN4lHzgh7TAF7XSB2Ylfgx8zTlB5ss+33+egbm1968lgrPZ0tVd0VMIiIZAudzGwLhfMl9PdK0sHQPvbvor6596Dr4Bld/qI8hBOSPekdRFX2qvU+yBP4QNRJylhh6ytCCzQOhZCoqos2Oe8=
Content-Type: multipart/alternative; boundary="_000_GVXPR07MB9678CA51D390749E905BC7C389332GVXPR07MB9678eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GVXPR07MB9678.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93719f81-5ea9-4d0d-a26e-08dc4896dcc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2024 04:33:16.5719 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GxC8q2TyuATMFiG2u56zrJgbJ5rqfpx7ZsxgpoAypuYVivv0RvHZFMEFgLnhlzSxb+qPV2KjRimjCnBZvFJSsLrQCYF2HsNcP8yb519jYZQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR07MB8388
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_YPAmOnqSPpw9wGDNokTpY9CepQ>
Subject: Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 04:33:25 -0000

Sounds good to me. That makes the solution very simple.

The new extension would then work very similar to RFC 8449.

The ExtensionData of the "large_record_size" extension is

      uint32 LargeRecordSizeLimit;

When negotiated, all records protected with application_traffic_secret are changed:

OLD:
      struct {
          ContentType opaque_type = application_data; /* 23 */
          ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
          uint16 length;
          opaque encrypted_record[TLSCiphertext.length];
      } TLSCiphertext;

NEW:
      struct {
          uint32 length;
          opaque encrypted_record[TLSCiphertext.length];
      } TLSLargeCiphertext;

OLD:
      0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |0|0|1|C|S|L|E E|
       +-+-+-+-+-+-+-+-+
       | Connection ID |   Legend:
       | (if any,      |
       /  length as    /   C   - Connection ID (CID) present
       |  negotiated)  |   S   - Sequence number length
       +-+-+-+-+-+-+-+-+   L   - Length present
       |  8 or 16 bit  |   E   - Epoch
       |Sequence Number|
       +-+-+-+-+-+-+-+-+
       | 16 bit Length |
       | (if present)  |
       +-+-+-+-+-+-+-+-+
NEW
      0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |0|0|1|C|S|L|E E|
       +-+-+-+-+-+-+-+-+
       | Connection ID |   Legend:
       | (if any,      |
       /  length as    /   C   - Connection ID (CID) present
       |  negotiated)  |   S   - Sequence number length
       +-+-+-+-+-+-+-+-+   L   - Length present
       |  8 or 16 bit  |   E   - Epoch
       |Sequence Number|
       +-+-+-+-+-+-+-+-+
       | 32 bit Length |
       | (if present)  |
       +-+-+-+-+-+-+-+-+

From: TLS <tls-bounces@ietf.org> on behalf of Martin Thomson <mt@lowentropy.net>
Date: Wednesday, 20 March 2024 at 13:47
To: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS
In offline discussion l was convinced that a bigger change might be needed.  The shifting is cute, but we might be able to do better.

This won't be wire compatible with the existing protocol, so maybe just embrace that and change the record header.  This would happen when switching from handshake protection to application data protection.  We can drop the version and content type and reclaim some of the savings for a longer length field.

On Wed, Mar 20, 2024, at 13:42, John Mattsson wrote:
> Hi,
>
> My summary from the TLS WG session yesterday:
>
> - Let’s adopt and figure out the final details later.
> - Show performance data.
> - Should be new extension, i.e., not used together with "record size
> limit".
> - The new extension should redefine the meaning of the uint16 length
> field in the TLSCiphertext to allow records larger than 2^16 bytes.
>
> Simple suggestion:
>
> In the new extension the client and server negotiate an uint8 value n.
> Client suggest a value n_max. Server selects n where 0 <= n <= n_max or
> rejects the extension. Agreeing on a value n means:
>
> - The length field in the record means 2^n * length bytes instead of
> length bytes. I.e., left shifted similar to the TCP window scale option.
> - The client and server are willing to receive records of size 2^n *
> (2^16 - 1) bytes.
> - Up to 2^n - 1 bytes of padding might be required.
> - AEAD limits are reduced with a factor 2^(n+2).
>
> Thought?
>
> Cheers,
> John Preuß Mattsson
>
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Tuesday, 5 March 2024 at 06:16
> *To: *John Mattsson <john.mattsson@ericsson.com>, Michael Tüxen
> <tuexen@fh-muenster.de>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,
> Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, John Mattsson
> <john.mattsson@ericsson.com>, Michael Tuexen <tuexen@fh-muenster.de>
> *Subject: *New Version Notification for
> draft-mattsson-tls-super-jumbo-record-limit-02.txt
> A new version of Internet-Draft
> draft-mattsson-tls-super-jumbo-record-limit-02.txt has been successfully
> submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name:     draft-mattsson-tls-super-jumbo-record-limit
> Revision: 02
> Title:    Large Record Sizes for TLS and DTLS
> Date:     2024-03-04
> Group:    Individual Submission
> Pages:    6
> URL:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mattsson-tls-super-jumbo-record-limit-02.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406539633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OMjrxOxbWsSB2PBCpAi83OzLPPdnJEP%2F1lyBB1EvFLM%3D&reserved=0<https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.txt>
> Status:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-tls-super-jumbo-record-limit%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406546672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XVjTKWNaluHBY%2FVWzSJ7p5uOg3lGGi7kj6rGf8xTwxU%3D&reserved=0<https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/>
> HTML:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mattsson-tls-super-jumbo-record-limit-02.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406552176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FVvxBRpt%2FzNzB3gSuibaLV4VjAiWmsR5CM94OmZVy3o%3D&reserved=0<https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.html>
> HTMLized:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mattsson-tls-super-jumbo-record-limit&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406556177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Lcmo5nY%2Fxq9iCsIrMtqzwr2banzyxaqpM6R5MJzht0o%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit>
> Diff:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-mattsson-tls-super-jumbo-record-limit-02&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406560362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=00G5NyvowjgAW7WWiXjmD337Zf%2Fw%2FNgaT2PRfXzMrcg%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-02>
>
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406564817%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AMG1oWGtRdyPeRK5NaqPf6PhjzTSDSgFRFfj8ktqHWQ%3D&reserved=0<https://www.ietf.org/mailman/listinfo/tls>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406568465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ec0BixMocrt%2BxBU91HaQ3v6oLemcc5IzsMiJE%2FmxiNU%3D&reserved=0<https://www.ietf.org/mailman/listinfo/tls>