Re: [TLS] custom lower limit of record_size_limit

Martin Thomson <> Tue, 22 January 2019 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7505B131141 for <>; Tue, 22 Jan 2019 13:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=gwox+cyB; dkim=pass (2048-bit key) header.b=xmbIErcQ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bv-zXLEPJfrD for <>; Tue, 22 Jan 2019 13:33:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 542AA131133 for <>; Tue, 22 Jan 2019 13:33:51 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id 694AF142A8; Tue, 22 Jan 2019 16:33:50 -0500 (EST)
Received: from web6 ([]) by compute1.internal (MEProxy); Tue, 22 Jan 2019 16:33:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=HgO q+bry0BpWpxo52u7G9kuygzlkx0rKOYcV8wibo1Q=; b=gwox+cyBJ6h3+Hz9J8k t+CyKydnu6rstbgzLX4YT/nlo0ay8X5Ujl95iWpmH+vcDYCjy+u/qZddsD2xsvnM xlzXDwdR7ojMH6Ud0B/zzBERmHhvvjSmLZYa93sxlatMzS4xvRr9KATkfutWHD7y MlpJnn8LWO2jw1U7LgWnQ4W51caaR0wylTOeuOr02XCh2oGYkeaanI/9WCtKRb6b 0D4DC4SbJafPSuGyNsDHeGrUB0OjVLkHIPGutXmsnfKpCehlKR9TUr0eRhonY54b abgUYCf7o3d5p0Pk2/+TVoJkv7a7/IR/phd5TZxUZDWxhBXyPyg4IPVjrYeQsBnE 2SQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HgOq+bry0BpWpxo52u7G9kuygzlkx0rKOYcV8wibo 1Q=; b=xmbIErcQL28NytoI5S/w+Czipg7OIl4zpHn0e8Q0+udK+pThNi2elznGO D4hPHb+Kl3yTWwntX0U+jp/fA1KPj6XFMj5vHcAKUKpfRTiXkoaWrKyed0AswGfj Nvwrp66USDvq48OA1fICkEU5HLiBEPe3kOQpKtAR15HlQRB+11XY3T0LFxxCIedb vSGaaqE4G21DnRQKlqhrVXEy62OHwyEGeBuQ3X4i2petidm0JV+N573Ezq8M7mQb lbjUF6wgztFMPTsSFCe1aOiRc8uvQDRnvpMaoELRZG5S5I6pNG1nVarNJ2KKVWmG BETrbSDFd8re6qjlLvi/yZZIYQSMg==
X-ME-Sender: <xms:PYxHXLz2LfhRqUDfqpKDcanmIhugpusitB1Rtf8DJU0GVFDY800Qqw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheekgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fofhffjgfusehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:PYxHXHjrsxV4aLjhzHgqi4VojcVN4JB77h5YVG1sJzsSmZzkAPaZMQ> <xmx:PYxHXAX_c8c10lTWWvPASmvhHXADJHnJZHO6ycvdl9utQK7_GJxK8w> <xmx:PYxHXJ0cHaGB0Xfi_P_XlL8y4zyqDl6GLnTCjdVTN6hlyvk4UCjPyA> <xmx:PoxHXA-w_Nh_KehYau1Awq7eZBkHOmh1eTLX5jRmgAZM69G0MtGx8A>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 999684146; Tue, 22 Jan 2019 16:33:49 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
To: Nikos Mavrogiannopoulos <>,
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-36e4bfd3
References: <> <> <>
Date: Wed, 23 Jan 2019 08:33:49 +1100
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] custom lower limit of record_size_limit
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jan 2019 21:33:53 -0000

On Mon, Jan 21, 2019, at 19:03, Nikos Mavrogiannopoulos wrote:
> I do not think that 64 is not hard to implement, but I think it is very
> hard to implement it in a way that it is efficient. 

Totally agree.  There's like a curve for performance with an asymptote as records get bigger and a steep incline as records get smaller.  I picked 64, not because it is good - it's clearly terrible for performance - but because it was a power of 2 that was enough bigger than the handshake overhead that you couldn't configure a connection that was guaranteed to be unusable.  32 might have been enough, but it's pretty ludicrous, especially in DTLS.

I didn't want to make this a performance consideration.  Clearly 128 is much better than 64 performance-wise, but then 256 is better again.  Where on that curve your preference lies will depend on your constraints.  In the end, if a peer wants 64 and that would degrade performance too much for you, then you have a choice: don't negotiate the extension, or - for clients that don't get this choice - don't communicate with that peer.