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

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 20 March 2024 01:24 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 BB1E6C14F685 for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 18:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 vIdIwYdeWoFi for <tls@ietfa.amsl.com>; Tue, 19 Mar 2024 18:24:04 -0700 (PDT)
Received: from a1004.mx.srv.dfn.de (a1004.mx.srv.dfn.de [194.95.233.6]) (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 CF244C14F605 for <tls@ietf.org>; Tue, 19 Mar 2024 18:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:in-reply-to:organization:from:from :references:content-language:subject:subject:user-agent :mime-version:date:date:message-id:received; s=s1; t=1710897803; x=1712712204; bh=fJ58E/QPbWdB/gdFolf8yW5ah8T/Op8x77JLQa7uK8s=; b= rc2FZuXEM0mFj5weYR60rfl6kFFRltYFOUMQUCrqk5Wh78TxTez8uZTxexvSH+y8 5bZoARXyC6qGjZrSg5VAaBJu/1DznDjASR0OSa9OmA3hQNDql1lW5dvbpyOkO+Ss qC3ZxYXWKgLNjOJeTqbm2qbp9datgGcsFxH8sg4giRw=
Received: from mail.dfn.de (mail.dfn.de [194.95.245.150]) by a1004.mx.srv.dfn.de (Postfix) with ESMTPS id 649182000DC for <tls@ietf.org>; Wed, 20 Mar 2024 02:23:23 +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 9DA8D3D6 for <tls@ietf.org>; Wed, 20 Mar 2024 02:23:22 +0100 (CET)
Message-ID: <a7680e90-dc3c-4a04-8d84-b0bbdbc5d354@dfn.de>
Date: Wed, 20 Mar 2024 11:23:17 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: tls@ietf.org
References: <1a500de6-8135-447b-ad28-66d22ef31fd3@dfn.de> <CAF8qwaB-HFKEeRZzzEEPzw-nWD1FQCHOmP=DYnpbPJsDJnbJSQ@mail.gmail.com>
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
In-Reply-To: <CAF8qwaB-HFKEeRZzzEEPzw-nWD1FQCHOmP=DYnpbPJsDJnbJSQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms090308030203030407050407"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/msiovsjU6W7cSzKfpbLojG2PKwE>
Subject: Re: [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 01:24:08 -0000

On 20.03.24 11:08, David Benjamin wrote:
> I can't say what was going on in the SSLv3 days, but yes record size 
> limits are important for memory. Whatever the maximum record size is, 
> the peer can force you to buffer that many bytes in memory. That means 
> the maximum record size is actually a DoS parameter for the protocol.

Ok, that at least confirms the theory.
The difference between 16KiB and 64KiB seems small with current 
computers, but I suppose back in the SSL days this was a huge difference 
and a nice side effect for current embedded systems with limited memory.


I think what puzzled me most was that there was no explanation at all 
about why that limit is there. It seemed a bit random (why 2^14 and not 
2^15 or 2^10), and whenever there is a restriction like that, IMHO there 
should be some explanation as to why it is that way.

Looking at specs from an implementer's and researcher's view, 
implementers want to understand why they need to follow specific 
restrictions, researchers want to know what assumptions were made, so 
they can prove that the assumptions were correct (or use that assumption 
in their research).

Also for future specifications, it's always good to have rationales so 
you can understand if a proposal that would change that (like the Large 
Record Sizes draft) would break things or not.
Maybe there is a not immediately obvious reason as to why a 
seemingly-arbitrary restriction is put in place.

But I guess this is not an issue single to TLS, but for all IETF documents.


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