Re: [Cfrg] Proposed requirements for curve candidate evaluation
Tanja Lange <tanja@hyperelliptic.org> Fri, 08 August 2014 18:44 UTC
Return-Path: <tanja@hyperelliptic.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD23A1A008C for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 aSTzrs_N8ff9 for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:44:18 -0700 (PDT)
Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id D26E21A009E for <cfrg@ietf.org>; Fri, 8 Aug 2014 11:44:17 -0700 (PDT)
Received: (qmail 16690 invoked from network); 8 Aug 2014 18:44:07 -0000
Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by mace.cs.uic.edu with SMTP; 8 Aug 2014 18:44:07 -0000
Received: (qmail 12809 invoked by uid 1000); 8 Aug 2014 18:44:04 -0000
Date: Fri, 08 Aug 2014 20:44:04 +0200
From: Tanja Lange <tanja@hyperelliptic.org>
To: Michael Hamburg <mike@shiftleft.org>
Message-ID: <20140808184404.GN28679@cph.win.tue.nl>
References: <f9d9c886d08e4a4eb09c4a57584f950b@BL2PR03MB242.namprd03.prod.outlook.com> <4EBC943C-77A4-417C-B29C-D18E00F1AEAD@shiftleft.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4EBC943C-77A4-417C-B29C-D18E00F1AEAD@shiftleft.org>
User-Agent: Mutt/1.5.11
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/iXvdoYLobd_dMK0RXhDhgFkyMVc
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] Proposed requirements for curve candidate evaluation
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 18:44:21 -0000
On Thu, Aug 07, 2014 at 11:57:45AM -0700, Michael Hamburg wrote: > > > On Aug 7, 2014, at 7:20 AM, Brian LaMacchia <bal@microsoft.com> wrote: [..] > > 4. When evaluating candidate curves for use in ECDHE, "ephemeral" should be defined as "use exactly once in a key exchange" (or for TLS "use in exactly one handshake"). > > > > During the second TLS meeting in Toronto, Kenny Paterson gave a presentation summarizing where CFRG was on this question at that time and one of the points he mentioned was that there was not consensus as to what "ephemeral" should mean for purposes of evaluating candidates. Russ Housley then commented at the microphone that "ephemeral" should mean "used in exactly one handshake". I strongly concur with Russ's position and suggest that we formally adopt that definition now during the Requirements phase. The concrete implication of adopting this proposed requirement is that it means when we evaluate ECDHE performance for curve candidates we must include one fixed-base and one variable-base operation. > > I agree that this is what “ephemeral” should mean for evaluation. But I don’t understand how this clarification could possibly change anything. > I would like to clarify that we're talking about different kinds of evaluations: a) For performance evaluations one can argue that ephemeral means one handshake (or a short time or a small number of connections). b) For security evaluations we must take into account that users may keep reusing the same key; this must not be a problem for the security of the curve or the implementation. Tanja
- [Cfrg] Proposed requirements for curve candidate … Brian LaMacchia
- Re: [Cfrg] Proposed requirements for curve candid… Michael Hamburg
- Re: [Cfrg] Proposed requirements for curve candid… Benjamin Black
- Re: [Cfrg] Proposed requirements for curve candid… Salz, Rich
- Re: [Cfrg] Proposed requirements for curve candid… Michael Hamburg
- Re: [Cfrg] Proposed requirements for curve candid… Salz, Rich
- Re: [Cfrg] Proposed requirements for curve candid… Watson Ladd
- Re: [Cfrg] Proposed requirements for curve candid… Michael Hamburg
- Re: [Cfrg] Proposed requirements for curve candid… Andrey Jivsov
- Re: [Cfrg] Proposed requirements for curve candid… D. J. Bernstein
- Re: [Cfrg] Proposed requirements for curve candid… Tanja Lange
- Re: [Cfrg] Proposed requirements for curve candid… David Jacobson
- Re: [Cfrg] Proposed requirements for curve candid… Craig Costello
- Re: [Cfrg] Proposed requirements for curve candid… Michael Hamburg