Re: [TLS] custom lower limit of record_size_limit

Martin Thomson <> Mon, 21 January 2019 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD537130E2F for <>; Sun, 20 Jan 2019 21:13:51 -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=CGSP4Q6Y; dkim=pass (2048-bit key) header.b=mvsTTElp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hr2YB6-mTxZ1 for <>; Sun, 20 Jan 2019 21:13:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBE23130DE9 for <>; Sun, 20 Jan 2019 21:13:49 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id B005A15FF9 for <>; Mon, 21 Jan 2019 00:13:48 -0500 (EST)
Received: from web6 ([]) by compute1.internal (MEProxy); Mon, 21 Jan 2019 00:13:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=bHZ rodyRpcX1qxn3EYg8TUh7hF/G9GpucxR4p/+u5Rg=; b=CGSP4Q6YlduBLVhlJ2k 3cddKG+nocOjc4rNKpKcd9i3jq9/8laRlkUxe05oTVQtiLvnuyvUJJD3CEtZZ1pH EzP+iXlH5kxnro2bTDjq0MjbQM3IRWlV06+B33SLCZV5txi2abrgKPtJzwtg+qqy J8I8fnU64ENsAfd9dB/DDKDNnaAQ8HeeiKt6Ax3idmatvyy6kVr2ymz8/je3JVLY JqsL1oQabOXIrUYrQqwJaQoS3tmgqYZN8GNaaWUmkQ2yjQAbTLluxN5OxlwHVUvM z9azkMJ1Rbg92lKTbjrIRxIGODDFZcmWC9/nrO2KEigODOjnBXkG3vIeeFB0ktOo RPQ==
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=bHZrodyRpcX1qxn3EYg8TUh7hF/G9GpucxR4p/+u5 Rg=; b=mvsTTElpAv3K54quBrLDm+O+Iof1kbC7S/Z7NfR2fEJB+05fwNzfY8WbD h6likQzeCWO89j6VFt4CFS5KDyLSRbEWn4nUbKDx4dnSd5y7MhnNgYY/BCu0sn6m JCza6vSyHyFMenEQF6AigLYwrp/Hy2Va4R2iRR/A9JcQ2263VUrgTt7/wqTEo18x PJtGhNoacO2A+vDCICLtv4Eedmz/9NrgNEQmWR4W9w6kWsJNAMZwDmNK+P3BNErX WBpPM0bYCaEzVq7FWwgPhA0T3OOUhljttwWdbsCGb3Ljybs7VQA9RYyBpG+vmIHR XMnvxlvtGTKkLAI5B3jtVC6kekNdA==
X-ME-Sender: <xms:C1VFXMoxomrOHr-qhrRgSrzjS3AdVJSqdrXixyHvfJyp3YJtmMw6qw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheehgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:C1VFXGeDt3mi7cIQekdVma79XtMfXszYfxUwtuJW-0KzR698P8K1Jw> <xmx:C1VFXKTccnpd6Z-ZWBKz9f86vcWotDbWxHy1Mw9Jo7rxtplnfybijw> <xmx:C1VFXHalLWifFddCNINpS_kseTYxrBNPJHssn--WYWT94UTcoEd0JA> <xmx:DFVFXHXwkKvOePPdTOttZH9ubGZ_w72287TLuSbvbm2U7AzKR0FanA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 582D54146; Mon, 21 Jan 2019 00:13:47 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-36e4bfd3
References: <>
In-Reply-To: <>
Date: Mon, 21 Jan 2019 16:13:47 +1100
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: Mon, 21 Jan 2019 05:13:52 -0000

On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote:
> My interpretation is that, if the client sent "record_size_limit" but
> didn't receive the extension from the server, that would mean the
> extension was not negotiated and the server may not respect the limit.
> Is this correct, or 64 is really mandatory to implement?

Unfortunately, if you want your peer to respect your limit, then you have to be willing to generate very small records.

BTW, 64 is entirely an arbitrary number.  It's at the point where the overheads get really noticeable, so performance is probably pretty bad well before you get to this point.  But we didn't get any indication that it was impossible to go that low.

If there had been feedback about it being too small, I'm fairly sure that a large number would have been fine.  Do you know why 64 is considered too hard to implement?