[TLS] TLS Record Size Limitation

Software Engineer 979 <softeng979@gmail.com> Mon, 07 December 2015 21:00 UTC

Return-Path: <softeng979@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F41A883C for <tls@ietfa.amsl.com>; Mon, 7 Dec 2015 13:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.349
X-Spam-Level:
X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWzjllgH9Dcb for <tls@ietfa.amsl.com>; Mon, 7 Dec 2015 13:00:55 -0800 (PST)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E853B1A87A0 for <tls@ietf.org>; Mon, 7 Dec 2015 13:00:54 -0800 (PST)
Received: by ioc74 with SMTP id 74so307420ioc.2 for <tls@ietf.org>; Mon, 07 Dec 2015 13:00:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2b0rgWTHaE9bmAwe0z0hLUx9Y/ALC8m0neu4e5TecKI=; b=eW2kgKYc1mkSKydidbvQWPxaM+0IdDCHP4lgEhlCYgc3r7DvF/teVTUXc4MNEdUha0 x3c20b/Um/wmyIe1jtUs4FtVwhaZZQsEMK1W9H0LmUnWXb++d8JzzG6t/Bo2kxhGQCcM VRz+b5lpJyhO97HSakMGmP3eBLp8o2KzhzezPzQUGp5YwvGMruvDyQ13FK7BpCRkSsa3 rHhvWFScaPWatCM3DVWsKCZptTFly0BLMnJHchE925Btc2XqCS/bLiNiUsN3aW2eEOaP BOGUkPYbf2yQYiy2G0HiFeL6olUuF1E5ESATxrWQxSFJIbB8mZBiP3cLeKdmXU1fXVc1 GtPg==
MIME-Version: 1.0
X-Received: by 10.50.109.136 with SMTP id hs8mr378601igb.93.1449522054279; Mon, 07 Dec 2015 13:00:54 -0800 (PST)
Received: by 10.107.146.138 with HTTP; Mon, 7 Dec 2015 13:00:54 -0800 (PST)
Date: Mon, 7 Dec 2015 15:00:54 -0600
Message-ID: <CANSok=bDBCo4ko9WAoTurt84Krinpsf6_=g3Hq0-JWiiSo3WjQ@mail.gmail.com>
From: Software Engineer 979 <softeng979@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=089e013a213e23b7cf052655274c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/K_6Ug4GtAxbrQJy2CFFFoxxtJ60>
X-Mailman-Approved-At: Mon, 07 Dec 2015 20:26:40 -0800
Subject: [TLS] TLS Record Size Limitation
X-BeenThere: tls@ietf.org
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." <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: Mon, 07 Dec 2015 21:01:46 -0000

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.