Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and

Eric Rescorla <ekr@rtfm.com> Thu, 17 February 2011 09:34 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05593A6D69 for <tls@core3.amsl.com>; Thu, 17 Feb 2011 01:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.927
X-Spam-Level:
X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx7MxMhFeKUO for <tls@core3.amsl.com>; Thu, 17 Feb 2011 01:34:58 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 18B453A6D8C for <tls@ietf.org>; Thu, 17 Feb 2011 01:34:58 -0800 (PST)
Received: by iym1 with SMTP id 1so2290592iym.31 for <tls@ietf.org>; Thu, 17 Feb 2011 01:35:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.228.5 with SMTP id jc5mr2397065icb.228.1297935328336; Thu, 17 Feb 2011 01:35:28 -0800 (PST)
Received: by 10.42.178.193 with HTTP; Thu, 17 Feb 2011 01:35:28 -0800 (PST)
In-Reply-To: <4D5CE08C.5060402@gnutls.org>
References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org>
Date: Thu, 17 Feb 2011 11:35:28 +0200
Message-ID: <AANLkTimsFTBw=WtOopKfQkPnKJJH83kaHYuN89GBLEPC@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 17 Feb 2011 09:34:59 -0000

On Thu, Feb 17, 2011 at 10:47 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> On 02/17/2011 01:03 AM, Michael D'Errico wrote:
>> I see the potential problem.  For me, though, I just hold onto all
>> of the handshake messages until the handshake concludes.  It may use
>> a bit more memory for a short amount of time, but the issue you raise
>> is completely avoided.  Call it a space <-> code complexity
>> trade-off.
>
> Indeed. There is no other way to correctly implement TLS 1.2 except
> from holding a copy of all the handshake messages. This is problematic
> when converting an implementation of TLS 1.0 or 1.1 to that, since
> those protocols only required to hold the state of 1 or 2 running hashes.

Is that really true?. My memory from the discussions and briefly
refreshed by looking at the
doc is that you only need to hold the messages until you see the
ServerHello at which point
you know the PRF and so you can just start storing hashes.

Best,
-Ekr