Re: [TLS] TLS Record Size Limitation

Yoav Nir <> Tue, 08 December 2015 09:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9213A1A92EB for <>; Tue, 8 Dec 2015 01:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GBNzesxAauj5 for <>; Tue, 8 Dec 2015 01:32:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D8DD1A92EC for <>; Tue, 8 Dec 2015 01:32:21 -0800 (PST)
Received: by wmww144 with SMTP id w144so173427636wmw.1 for <>; Tue, 08 Dec 2015 01:32:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EViUL2uSJ3M0Nkflz3VwFzdWJSxdbgVgwQESckc2Fpk=; b=Qhir55kAzG8XJ0DzXDqxvntI2wCQrrpghIprM7/q7Omk64UOEfJnn475BkyX0Wx9ZV dtnt1RJXiMibN/9FFBTZUeim9/xsWaxnlOONskrYd6kQntCurOFC1y0H+vhc8zuaII/v /bM2uffuyZM7EUUNlz3GUK2TgWEFFDLFzrJm4euDpVknIq8MADVsbiPwewlv5Sno1qtI Fx3mCV3CIYYLEoKzyo4MnZ9rc/9CgmionD3hcg/XthFKknELKJ6fodv48yE6U5Wbg0HT fU9Jm07XTO8HEMdwKyvr4xnaSBmOmwaHdS8pzKiPLHNsYVNoa395+vbvXaFPbWarA0r9 R+fg==
X-Received: by with SMTP id fm4mr3028328wjc.152.1449567140050; Tue, 08 Dec 2015 01:32:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s11sm2595305wmb.14.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 01:32:19 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_259B588D-B3DA-4865-BBEE-69DC1D5DBDB9"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 8 Dec 2015 11:32:13 +0200
Message-Id: <>
References: <>
To: Software Engineer 979 <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Subject: Re: [TLS] TLS Record Size Limitation
X-Mailman-Version: 2.1.15
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, 08 Dec 2015 09:32:23 -0000

> On 7 Dec 2015, at 11:00 PM, Software Engineer 979 <> wrote:
>> Hello,
>> I'm currently developing an data transfer application using OpenSSL. The application is required to securely transfer large amounts of data over a low latency/high bandwidth network. The data being transferred lives in a 3rd part application that uses 1 MB buffer to transfer data to my application. When I hook OpenSSL into my application I notice an appreciable decline in network throughput. I've traced the issue the default TLS record size of 16K. The smaller record size causes the 3rd party application's buffer to be segmented into 4 16K buffers per write and the resulting overhead considerably slows things down. I've since modified the version of OpenSSL that I'm using to support an arbitrary TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since this change, my network throughput has dramatically increased (187% degradation down to 33%). 
>> I subsequently checked the TLS RFC to determine why a 16K record size was being used, and all could find was the following:
>> length
>>       The length (in bytes) of the following TLSCompressed.fragment. 
>>       The length MUST NOT exceed 2^14 + 1024.
>> The language here is pretty explicit stating that the length must not exceed 16K (+ some change).Does anyone know the reason for this? Is there a cryptographic reason why we shouldn't exceed this message size? Based on my limited experiment, it would appear that a larger record size would benefit low latency/high bandwidth networks.

This is only a guess, but you usually want to fetch the entire record off the network before you begin decrypting and checking MAC (unfortunately, it that order), so the intention was to limit that amount of buffering the receiver is required to do. Perhaps also allow for more parallel network fetching and decryption.  In either case, these are decisions made almost 20 years ago in SSLv3, and they may or may not make sense today. Although with all the IoT devices, it might make even more sense today to reduce buffering requirements.