[TLS] Question about Large Record Sizes draft and the TLS design

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 20 March 2024 00:35 UTC

Return-Path: <rieckers@dfn.de>
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 34CCBC151552 for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 17:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, 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 (1024-bit key) header.d=dfn.de
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 Gx0Mvk_0ULcg for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 17:35:41 -0700 (PDT)
Received: from b1004.mx.srv.dfn.de (b1004.mx.srv.dfn.de [IPv6:2001:638:d:c302:acdc:1979:2:58]) (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 BF1B9C151996 for <tls@ietf.org>; Tue, 19 Mar 2024 17:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:organization:subject:subject:from:from :content-language:user-agent:mime-version:date:date:message-id :received; s=s1; t=1710894935; x=1712709336; bh=jKfa+j71eq/5wlYU SfYfGh/sFa6Nx/R2PZWggmy9H/M=; b=agxgYuVWwFgxwiaaQYkDz2S4K009mfNT tMg4oGtax3cVzKXsupv8i/raNDgdTqqQZ/gSdHdn96kxaNFSed1aqFngEa9Vq0TP c6FsSsqPh3PvRlggbGuO93H7qi76NJbUyUY98VuIhKdIeXDITOp+qN6bzXtLMV1z 3fnL6dX/S9I=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by b1004.mx.srv.dfn.de (Postfix) with ESMTPS id A95FC2200DA for <tls@ietf.org>; Wed, 20 Mar 2024 01:35:35 +0100 (CET)
Received: from [IPV6:2001:67c:370:128:e50f:ae49:e9e9:6081] (unknown [IPv6:2001:67c:370:128:e50f:ae49:e9e9:6081]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.in.dfn.de (Postfix) with ESMTPSA id D5ABB3D6 for <tls@ietf.org>; Wed, 20 Mar 2024 01:35:34 +0100 (CET)
Message-ID: <1a500de6-8135-447b-ad28-66d22ef31fd3@dfn.de>
Date: Wed, 20 Mar 2024 10:35:29 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: tls@ietf.org
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms090902050404080407040506"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/10v6jII-P-TUg7ICf_3zGZyEIIU>
Subject: [TLS] Question about Large Record Sizes draft and the TLS design
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 00:35:45 -0000

Hi to all,

during the presentation of the Large Record Sizes draft at the tls 
session yesterday, I wondered why the length restriction is in TLS in 
the first place.

I have gone back to the TLS1.0 RFC, as well as SSLv3, TLS1.3 and TLS1.2 
and have found the restriction in all of them, but not a rationale why 
the length is artificially shortened, when the length is encoded as uint16.

Does someone know what the rationale behind it is?
One educated guess we came up with was that the limit was put there to 
ensure that implementations can make sure to not use too much memory, 
and using 2^14 was deemed a good compromise between memory usage and 
message length, but in my short research I haven't found any evidence 
that would confirm that guess.


Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822