Re: [Cfrg] Proposed requirements for curve candidate evaluation

David Jacobson <dmjacobson@sbcglobal.net> Sat, 09 August 2014 03:06 UTC

Return-Path: <dmjacobson@sbcglobal.net>
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 2D11D1A03FF for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 20:06:55 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZHkeK83DSlJH for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 20:06:53 -0700 (PDT)
Received: from nm15-vm4.access.bullet.mail.gq1.yahoo.com (nm15-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96B11A003A for <cfrg@irtf.org>; Fri, 8 Aug 2014 20:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1407553612; bh=/dgSE3UNPUFf3SL5VDmKw2kVuu32uKa72CeuDIXtcOg=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dCP+DxIiXrQKY7EJ+wkZiXSEaXdsT6I99wnCyUItwyiq1wN2ViS2AyBZEOf5wPxhAGCEslwMedSfZ9qYEE9vqLKDpHddTiPHHeEB64s4TS9JxcLmB1alMhaRdm1FnVNvfWQWSL0A43GLRooqdxxF5VmbYfW9tN9JCQGkcCUqjvqcxL5M0PryfRavkpxuTq9qldFREi++rm+yO4ZmGw0d8p0JRM2opySJ2LSR+Ds07ic82gVgtoZBftReDmsAjJchNtLqwl3vtC3OP7aG/TgGPYGHCYcbuodYlJ791K8UH5oEA4DpPjPi8bwZUQv/X1+nzhYbJ4aHtbIEokMT+CTY2w==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=sbcglobal.net; b=gR0zpgrmNiT0mDt4hjMfC/kcLQuzgCm4HJh9as/T2m2s/zplQVkHUBzJNPC6006BakF/K1igpHiC4u8fI8cy5bXYt6TZVSCImewFdd6KKHE+3m5Ixnz1S6t8kU2wGn0or8RAqX+GNH9AwUaQ6cVafmv9XVsDWENnvLu+WPDZGzhJw/LzLELpC/x+wE/9RK1hjiTGealV4GOpCmW1a3YpvCCZMuewGcZN+S51GhP72OyRdQ1cvOoIG5UOcOW1BY+SsTCTauFS9pCHiuFn7vyCD/1eB7uQ60i+rqjdyLctCSHvI9hfaq0HWG4QuiEza6Nm6RAwvOpLrNyg+6gRf0+T0Q==;
Received: from [216.39.60.169] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2014 03:06:52 -0000
Received: from [67.195.23.148] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2014 03:06:52 -0000
Received: from [127.0.0.1] by smtp120.sbc.mail.gq1.yahoo.com with NNFMP; 09 Aug 2014 03:06:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1407553612; bh=/dgSE3UNPUFf3SL5VDmKw2kVuu32uKa72CeuDIXtcOg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LtN2689j2a0TYOzgkqErgTU3k0PvBmq5xfEDDWUxftr6GSk2Kht9/Fxg7IAlAItUCd0KgFr5gdVC5eGgrqVAxQ64ohnTxv58gkTy4LJ0aCkyobuugSQuq5PmtyVQ9FWzVskqARWN/ptgZqbihCGLJ2j8xwOGI/B+DYqlyWPGLWI=
X-Yahoo-Newman-Id: 339645.43189.bm@smtp120.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 4E82ZIoVM1m.FUiehYYaqTOjg8RRpZ.BtP7jHma2.f9OZi7 VkZfP57qwjuUiPKK7CU6YjIS4WhCDWIZFjOsp5FFd3w53HmbqXxbuvNWwRH0 i21cqGSpzQhhQKJqnp9g4v6t5fCeEb3rYWi2VNKHxtfOX1omLm2d0OdFMhoF pImbOd9f53S7m6xlM1zfOiivEgztlmG1iqKlDenw6vuiBfKhTs5fq6KxnigE 9NSUSoMPu9ehNCk1XIVzMe.ygcIW6LuzFTfbzJiCA2ow1Z_AgcBKS6YwCpHg MSWaIDTHsdT8Pv2nxG97ckzrRy7Byn6ed9HujZQojcRuHk3q6dW7eTA8JyLv Vimv637YHyWk05InqsiExhwtzSjMMdP2bklfUC.xj8dnjcZW_aVxGNQqfWfo AyU.C0lrSRPgEaD2uxtqTf5nYVBtgqdBoOpR8XrzD5TJWZGMh.k31XQgo5bw ZhqKOP7aMMuWfeHO8_h5Ofa61Cpdej4GB3e8SI7xwt7wpa8azIWhzbcTK5u7 R3WPg4RFmCIjzNCx7fQzquGrLEqXjBmgprnu6edXKZ8ntm18R18iYD4KBlb. TSWkIvOaqpcAwwQ0QAevantSXOY3hmM_4.QGxlQVT8lSBJ5IZinTOX9DCFcd V460p0SaZWKrtqOVF8Of4v2N07l5vdI2_qcgwLdxr821ba2SHDE00
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
Message-ID: <53E5904B.1020709@sbcglobal.net>
Date: Fri, 08 Aug 2014 20:06:51 -0700
From: David Jacobson <dmjacobson@sbcglobal.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <20140808180623.24424.qmail@cr.yp.to>
In-Reply-To: <20140808180623.24424.qmail@cr.yp.to>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/UoiABxZiV3q2n2B9Nkk9WWgnmHc
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: Sat, 09 Aug 2014 03:06:55 -0000

On 8/8/14 11:06 AM, D. J. Bernstein wrote:
> Brian LaMacchia writes:
> <snip>
>> 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").
> https://www.imperialviolet.org/2013/06/27/botchingpfs.html explains how
> keys can be kept around for months---despite meeting your definition of
> "ephemeral". These keys are clearly _not_ ephemeral and do _not_ provide
> perfect forward secrecy.
>
> As I explained in a previous message, "use for exactly one session" is
> the wrong policy; "use for exactly one connection" is the wrong policy;
> and Microsoft's current reuse-for-two-hours is also the wrong policy.
> These all fail to accomplish what the user wants, namely for keys to be
> erased very soon---I suggested 10 seconds as an upper limit.
> <snip>
> ---Dan
>
Dan is actually doing something much more fundamental that one might at 
first think.  He is changing the threat model.

Most people probably have the idea that ephemeral keys are more secure 
that longer term keys because they limit they amount of data relating to 
a particular key that a passive eavesdropper has access to, and thus 
make a cryptanalytic attack harder.  (I had that idea.)  But Dan is 
changing the treat model.    The threat is an attacker who can from time 
to time grab some amount of system state.  By Little's Law, the mean 
number of sensitive keys in the system is the throughput (sessions 
established per second) times the mean residence time of each key (in 
seconds), so the shorter the residence time, the fewer keys are there to 
get snitched.

Note that this depends on attacks grabbing some system info from time to 
time, perhaps by something like Heartbleed.  It also applies to things 
like the system state getting paged to swap, or written out in a crash 
dump.  It does not apply to an attacker who has thoroughly gotten 
control of the system and can grab and export data from every crypto 
operation.  In that scenario, the attacker gets everything, and 
shortening the residence time provides no benefit. (This is not an 
argument against Dan's proposal, rather just an observation.)

      --David Jacobson