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

Martin Thomson <mt@lowentropy.net> Wed, 20 March 2024 03:47 UTC

Return-Path: <mt@lowentropy.net>
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 4E6C5C151093 for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 20:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=lowentropy.net header.b="LLV78ePM"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="S3NVhduT"
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 RlL6CZWXMT64 for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 20:47:01 -0700 (PDT)
Received: from wfout3-smtp.messagingengine.com (wfout3-smtp.messagingengine.com [64.147.123.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A493C14F5FD for <tls@ietf.org>; Tue, 19 Mar 2024 20:46:56 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id BB1881C000DF for <tls@ietf.org>; Tue, 19 Mar 2024 23:46:51 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Tue, 19 Mar 2024 23:46:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1710906411; x=1710992811; bh=fN/3Yj2eDABiD3CFHX6WR62/krYDYEdkYaJuCkeup78=; b= LLV78ePMvbbo0j8eDrllSrBMQjIyex6mN2QTsaqwLBm6947FVRtovhuBnj49XLKl DU6k9DpWnAfVG5a01S1Kr9HpfbXP6Y6oBsZkZdFPahyKkMB33LoaM16MvMEqzvfg O8WYjUgdKjkWCw8OodMXxBsJRKCsDH7bAXdv/Bt5g6Bau0zk46HcSSbrQcZeUNFC fwoX3BGq0FZOPRMn9TAEKGFk/OT3YBj82NYjRT0Z9ZBWntGo4tRhz59RtgkXJa/S 6p31Xjds7LQLKOnaGFvBUev/Pgmn5EQ53XkzCuAMkr7BtHawcgb2h7cFS1h6PS9W hT73parSDhU7O/yJ1wrrqw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1710906411; x= 1710992811; bh=fN/3Yj2eDABiD3CFHX6WR62/krYDYEdkYaJuCkeup78=; b=S 3NVhduTzcIaRRFke9C5kE/aoFlEGFPeB4th9SQHrFgZR5QRc74QU9N6AUxmygcUK pEIcUaIOdAO/L0kndLWeFvfskzwW1Ne83kNNd1rNkUPp/Yw+UwgwEdzA1RDer9O6 x2vFS9NxzEQ4WXxB8RhMcKcWRE1rI3tSDFwUpUoAwKEszwwUp7Temp8FDAoJlBSj Vx2EyGiovbBjqGPSAGSQWtERbw5nfnZOOuS3/OY0dZUO1gEEDuew+pUXRP9m8EP+ 8Lt/SFmQJApsL+b3ryHwpKjP+tAl6yg0uF1X7Zzh6hoFjygD2ImnJRWMAYBhxfW+ bdSjIx/RKLOgd5ahuXggw==
X-ME-Sender: <xms:K1z6ZXpwlt1C6MaDxrAs5DFJAadGhTO0S8Azq70QPebDCiiWnm54Aw> <xme:K1z6ZRqciUZbTaCthCU3J8tEW6VfhE_B6T1sb_HoS4BPRwxKvJSiOHhRRirkwqDGF lkZT4R2-gpFRrkSp_8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrleefgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefftefgvedvhfdtffehje dufefhhfevhedufefhgfelleetieefgeefgffgleehgfenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:K1z6ZUMrLxaBA_UiRBz_pYRzaDxHk-JLOsto71pmQxPWCSRTFffiuQ> <xmx:K1z6Za4JmxNy4KFR7VmxJQqKt21XYjQlHehlzqliP5Xq5SRApnkMOQ> <xmx:K1z6ZW43YbB7R3eZgezQGGmiVCSWY3CbwYTFUNlsZfQNBhWRFPkOvA> <xmx:K1z6ZSgKgG-9mTA4G4RHwRH2ZPKWPsj-C7Ma2Yojh3MOStxsUOJx2Q> <xmx:K1z6ZcRcfGWlxo85dDMrK7bUXcz7CN_CX3utOc2jiBciRHImufZHUEuN1WM>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0BDE42340080; Tue, 19 Mar 2024 23:46:51 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940
MIME-Version: 1.0
Message-Id: <2099ebf2-f56f-47c7-9846-515bca19e299@app.fastmail.com>
In-Reply-To: <GVXPR07MB967894D717FD064E9690CC4A89332@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: <170958339152.58675.742327505310055736@ietfa.amsl.com> <GVXPR07MB967894D717FD064E9690CC4A89332@GVXPR07MB9678.eurprd07.prod.outlook.com>
Date: Wed, 20 Mar 2024 13:46:29 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SuKV6R_Xc7QlrHstqE-espDOWpE>
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 03:47:05 -0000

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://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
> HTML:     
> https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
> Diff:     
> 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://www.ietf.org/mailman/listinfo/tls