Re: [Cfrg] Requirements for curve candidate evaluation update

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 14 August 2014 12:26 UTC

Return-Path: <hallam@gmail.com>
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 137261A085F for <cfrg@ietfa.amsl.com>; Thu, 14 Aug 2014 05:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 YE6lcoOGkTSe for <cfrg@ietfa.amsl.com>; Thu, 14 Aug 2014 05:26:05 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1054A1A0ACF for <cfrg@irtf.org>; Thu, 14 Aug 2014 05:26:03 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id pv20so934514lab.29 for <cfrg@irtf.org>; Thu, 14 Aug 2014 05:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3tLFad7322nul7+8ss3PxJ9Yoqyw8/r2LEzpKR/43JQ=; b=vo8v9kMHqMKLFb/WbI3VNxZqG4OqdNCei2pDVj7fSWzhAU/q+6nmnKbaCCZ2c0h9fI yCVAEHzCWiD6iRsxX4zQ2GKhmaOXtSIPqrORoTgx/9NpfkcAYQsPIkzO9xJOW61fdVEt XrTDo1wAJfwt+oVf2Sbd5LzGs1+EG2UrZ/rIUzi0FwLcyPuD+WOHfbClwQW9NQilMq14 UTrGrKA+R1gI8pq66ekSqjaorNUhjDxz9QGlrlLHEoy7tqg83ZHHtvNCYJKSTqtXmZuw QkxbpiYzCJOxLYtbktrDyBTkAWcPUJWk0T6vnbi4/YDQPjNnxal46XhJUxDroLMKgUtN UKIQ==
MIME-Version: 1.0
X-Received: by 10.152.88.81 with SMTP id be17mr3393870lab.84.1408019161448; Thu, 14 Aug 2014 05:26:01 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.122.50 with HTTP; Thu, 14 Aug 2014 05:26:01 -0700 (PDT)
In-Reply-To: <53EC4DDD.7010503@akr.io>
References: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8CEB@USMBX1.msg.corp.akamai.com> <CA+Vbu7zfbx-OqU=ggXgutDb+GNwvS3QpkTwzU1c+2Lcv=3Gawg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C9094@USMBX1.msg.corp.akamai.com> <CAMm+Lwg8EZ-MWN4hKxzN+g5L9-GjgEGV49NqYNEnK=34qrkb+w@mail.gmail.com> <53EC4DDD.7010503@akr.io>
Date: Thu, 14 Aug 2014 08:26:01 -0400
X-Google-Sender-Auth: pI1AwTgOTH2xNtByJ_2RCa5j_m0
Message-ID: <CAMm+Lwh7BAGW6hQfqcDeciYk5nvePwe39Szo0zeCn9hrQLgNBA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Alyssa Rowan <akr@akr.io>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/bb5V9ncbMRfC3cN3Srcur1jhGXM
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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: Thu, 14 Aug 2014 12:26:07 -0000

On Thu, Aug 14, 2014 at 1:49 AM, Alyssa Rowan <akr@akr.io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 14/08/2014 03:42, Phillip Hallam-Baker wrote:
>
>> To be clear, I am arguing that we put HSM support way ahead of a
>> single model. HSM support is essential, a single model is
>> someone's idea of tidiness.
>
> That is a null property. Anything we can specify can be implemented in
> software or hardware. As I said before, there will _eventually_ be new
> HSMs, and new HSM firmware. People have already begun work on that.

What the constraint means is that if we come down to two curves and
little to choose between them and there is a significant difference in
the HSM situation then the curve that allows re-use of existing HSMs
wins, if neither does that then the curve that has support from HSM
manufacturers wins.

So folk peddling a curve would do well to line up HSM vendor support.


It isn't quite true to say that you can do everything in hardware or
software. There are very specific constraints here to do with side
channels and IPR that could have a huge bearing on what curve families
are viable and which are not.


> The commercial world of this are however glacially slow-moving, partly
> due to onerous and ineffective governmental certification requirements
> (one of the things that has been - rightly - criticised). Several do
> not support ECDSA (or ECDHE, where applicable) properly or at all, and
> this is why RSA is still far more common in the wild and ECDSA is
> quite honestly barely used by anyone publicly (there are _very few_
> ECDSA PKIX roots...) - those that are using it are running it in
> software and are therefore not relevant to your 'essential' requirement.

There are very few serious CAs. So its not surprising there are few
ECC roots. We have ECC roots, so do the other leading CAs. But the
reason for the lag has been IPR FUD.