Re: [TLS] record layer limits of TLS1.3

Yoav Nir <ynir.ietf@gmail.com> Thu, 24 November 2016 14:16 UTC

Return-Path: <ynir.ietf@gmail.com>
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 33C611295EF for <tls@ietfa.amsl.com>; Thu, 24 Nov 2016 06:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xVW2PvgnFsTc for <tls@ietfa.amsl.com>; Thu, 24 Nov 2016 06:16:46 -0800 (PST)
Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (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 36144129548 for <tls@ietf.org>; Thu, 24 Nov 2016 06:16:46 -0800 (PST)
Received: by mail-wj0-x236.google.com with SMTP id qp4so34552102wjc.3 for <tls@ietf.org>; Thu, 24 Nov 2016 06:16:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqMZXUN+RjSsPGF4rTLcg3hNNnbvZk+QvuJZPNyph/8=; b=voqafJ3x0AK8eOFP8TEbw/T1f3bg1T70qYXRZJ3LMGzKqNcO3jXRx6khDaW40eimIL x14+ygdN0/jsYD3Q5eyZzwV48aH0PpC4dRWR4RW1KF2QIxR605VVnTf3ofgB3TNr7bcb qg4tZivMse6pmr6BGSoY1+0rIiq3VmCYM39Tbm8M6oiUwzzc7Lfdapqno5F+MrtV45Rq qfXzRhzuL1PzUDYbchbsKIHxCgY+rgvsBjBEOFrt+qBK60PBX3hKDqryHFfHi4NPJPKJ 6eglZHHXuiVeuA2yd3JXOjTlPpk3efE0tiLtNAl2Pu3MHiKF4u34Y2wy2tY8tJ1Ifykk GgQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqMZXUN+RjSsPGF4rTLcg3hNNnbvZk+QvuJZPNyph/8=; b=ZV0PqADx71o6MGxZnME/O0qy+bXcb9yfy4l7x296zfBHkYepGHKX6RLC4tnlFs/Eda MJWMZE4ncbtZiEL0Ir8udpJo1MH8WOn8wHYkHh7kEBl6iGtHf9OO/szzBD8zJpwEyGw1 gL6YrboDuL15kYaLvkz1rIOIu/D/8RCJDxArUz305e2BNSoqHi2ikybB1nc+RiKFw6Lp hYRw1Tp9OyXQK4+eXsj6iAgClafib3uWgCVTueOMmrY1pDnzxibFVFN3/tjUa5pAJZ0f dll2PRULS6HDOAbiuOw3Mlpi3EDBV7esGdIX3l/NEFRwbsegHHx7cJN8JPYMf7Hga6+S PlWg==
X-Gm-Message-State: AKaTC03fwUjW90LlQJNb00jkhHVGjICbPmM+urtiXSwpo8nUdZDo+Sv8WuBi9sy1czgu6A==
X-Received: by 10.194.191.201 with SMTP id ha9mr2517401wjc.205.1479997004718; Thu, 24 Nov 2016 06:16:44 -0800 (PST)
Received: from [172.24.249.41] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id b7sm42070847wjm.39.2016.11.24.06.16.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 06:16:44 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <2015444.TtsXi0aiky@pintsize.usersys.redhat.com>
Date: Thu, 24 Nov 2016 16:16:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF04436D-5D2C-4BA9-BF5A-49158002CAD4@gmail.com>
References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> <2015444.TtsXi0aiky@pintsize.usersys.redhat.com>
To: Hubert Kario <hkario@redhat.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KeAzwbE1uXEhLECQJ0p-7azjbc8>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] record layer limits of TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 24 Nov 2016 14:16:49 -0000

> On 24 Nov 2016, at 15:47, Hubert Kario <hkario@redhat.com> wrote:
> 
> On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote:
>> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote:
>>>> Hi, Nikos
>>>> 
>>>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>> That to my understanding is a way to reduce
>>> latency in contrast to cpu costs. An increase to packet size targets
>>> bandwidth rather than latency (speed).
>> 
>> Sure, but running ‘openssl speed’ on either aes-128-cbc or hmac or sha256
>> (there’s no test for AES-GCM or ChaCha-poly) you get smallish differences
>> in terms of kilobytes per second between 1024-byte buffers and 8192-byte
>> buffers. And the difference going to be even smaller going to 16KB buffers,
>> let alone 64KB buffers.
> 
> this is not valid comparison. openssl speed doesn't use the hardware
> accelerated codepath
> 
> you need to use `openssl speed -evp aes-128-gcm` to see it (and yes, 
> aes-gcm and chacha20-poly1305 is supported then)
> 
> What I see is nearly a 1GB/s throughput increase between 1024 and 8192 byte blocks for AES-GCM:
> 
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
> aes-128-gcm     614979.91k  1388369.31k  2702645.76k  3997320.76k  4932512.79k
> 
> While indeed, for chacha20 there's little to no difference at the high end:
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
> chacha20-poly1305   242518.50k   514356.72k  1035220.57k  1868933.46k  1993609.50k  1997438.98k
> 
> (aes-128-gcm performance from openssl-1.0.2j-1.fc24.x86_64, chacha20-poly1305 from openssl master, both on 
> Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz)

Cool. So you got a 23% improvement, and I got an 18% improvement for AES-GCM. I still claim (but cannot prove without modifying openssl code (maybe I’ll do that over the weekend) that the jump from 16KB to 64KB will be far, far less pronounced.

Yoav