Re: [Cfrg] Requirements for curve candidate evaluation update

Benjamin Black <b@b3k.us> Thu, 14 August 2014 03:01 UTC

Return-Path: <b@b3k.us>
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 047301A0746 for <cfrg@ietfa.amsl.com>; Wed, 13 Aug 2014 20:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 DcPwRG2ELHBj for <cfrg@ietfa.amsl.com>; Wed, 13 Aug 2014 20:01:21 -0700 (PDT)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3141A0741 for <cfrg@ietf.org>; Wed, 13 Aug 2014 20:01:20 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so496704wgg.31 for <cfrg@ietf.org>; Wed, 13 Aug 2014 20:01:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=muJuUblT46Y3mD2lJhfsUbkQ4duVYd0OjMZGjOm0Y0Q=; b=kOiWPdyEexGTd6+v/fMy1kR/WIjcnf5x3EEuo0sOC1wEOnWygjSbRhIBRZt3qmhO10 Cfpqnxjn4nRNnxslq1XVCaiiS9ZlfSIRr7+zJMK0iGwFw+g0J2NMCr+ODSVUjkmBc8q6 W/pN7Thjd1uUgUdq3FJAoi10oTywJsPYmynZwiXSBwp8/UNX5p7r5BuGmhx8ILxI47+z 5RT8KcKe2kp0+FAVr3Tn+i6dCkDLDeGQmUiLObaoAi2Kw4phyejmXE/jnz478j1Q95YZ MMbpM/ywSIHpqqNnCI44ThX7rRpIGCdgRm2TgWMDloilENzpmFTuD7vbDwMlG0UbC7P6 AsCQ==
X-Gm-Message-State: ALoCoQlWPP5XneOoloQ9YHgPOsVSJJZmmaaIkg4eJ+s81b9pkvwSfhtOYtTOkfIe8GQ0X218A7uB
X-Received: by 10.194.76.133 with SMTP id k5mr8370928wjw.28.1407985279564; Wed, 13 Aug 2014 20:01:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.44.138 with HTTP; Wed, 13 Aug 2014 20:00:59 -0700 (PDT)
In-Reply-To: <CAMm+Lwh4DUEOH25sscu07A7FNzwL70xMCEjxRPNLb=6sYZP+EQ@mail.gmail.com>
References: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8CEB@USMBX1.msg.corp.akamai.com> <CAMm+LwikFfC7AoPyYn8EQsKXiv9X1uvGrdmwRXxiqcCSvNZsqA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C9093@USMBX1.msg.corp.akamai.com> <CAMm+Lwh4DUEOH25sscu07A7FNzwL70xMCEjxRPNLb=6sYZP+EQ@mail.gmail.com>
From: Benjamin Black <b@b3k.us>
Date: Wed, 13 Aug 2014 20:00:59 -0700
Message-ID: <CA+Vbu7xbKu+F8NPSjZUgs9ZrwdAkbJadKCRRf22rAX7kU=pNMg@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary=047d7bfcf7b07017d805008e1e89
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xKwyrwd7LeM6FTZMWWKkRAOui90
Cc: "cfrg@ietf.org" <cfrg@ietf.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 03:01:26 -0000

"The use of ECC to date in open standards based systems is so
insignificant that we really should not think twice about blowing it
all up and starting from scratch."

ECDHE is the default kx for Google, Microsoft, Facebook, Twitter, and many
other large service providers. Perhaps you mean ECDSA.

"And it really makes no sense to want to do that
and be shooting yourself in both feet by using signature keys for
encryption or vice versa."

Which encryption do you mean here?


b



On Wed, Aug 13, 2014 at 7:39 PM, Phillip Hallam-Baker <phill@hallambaker.com
> wrote:

> On Wed, Aug 13, 2014 at 10:27 PM, Salz, Rich <rsalz@akamai.com> wrote:
> >> Long term signature keys have to be generated and stored in HSMs
> >
> > So EDH keys do not, and therefore do not need HSM requirements, right?
>
> I don't see a large field of established use that would make
> availability of HSMs a gating factor for EDH. But obviously someone
> could come up with one.
>
> What I am trying to do here is to pare down the set of requirements
> WITHOUT throwing out any that could be show stoppers or gating
> deployment.
>
> The use of ECC to date in open standards based systems is so
> insignificant that we really should not think twice about blowing it
> all up and starting from scratch. But if we do that then someone has
> to tell the HSM vendors where we are going and some of them have to
> sign on.
>
>
> Not wanting to make a big fuss on the HSM requirement but it is
> definitely a potential gating factor. Using the same curve model for
> encryption and signature does not interest me in the slightest. I
> cannot see that as being a necessary requirement, it is just someone
> wanting things to be tidy.
>
> The only good reason to go to ECC right now is to get a bigger safety
> margin on your crypto. And it really makes no sense to want to do that
> and be shooting yourself in both feet by using signature keys for
> encryption or vice versa.
>
> The keys are plenty small enough to have separate encryption and
> signature keys. It would be no bad thing if we made it algorithmically
> impossible to attempt that type of abuse.
>
> I do want to junk the NIST curves though but not for the reason folk
> think. The big problem with ECC is the sheer length of time we have
> been waiting. Deployment is going to continue to be slow unless we get
> some sort of starting gun. One possibility is that the starting gun is
> breaking RSA1024 but having a new set of NSA-free curves agreed by
> IETF is good as well.
>