Re: [Cfrg] Comparing ECC curves

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 24 July 2014 02:56 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 9F63C1A02BA for <cfrg@ietfa.amsl.com>; Wed, 23 Jul 2014 19:56:29 -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 0bBsftqzEzgT for <cfrg@ietfa.amsl.com>; Wed, 23 Jul 2014 19:56:28 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98C51A0B07 for <Cfrg@irtf.org>; Wed, 23 Jul 2014 19:56:27 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so2033053wgh.35 for <Cfrg@irtf.org>; Wed, 23 Jul 2014 19:56:26 -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=x/O/U42X3eCnnEvF2QnFaHwiLEEnuH3yH+GAc+dgJyE=; b=z9PbiWisvBe1FC70jPnSb5aB033LKjE19rCN9xpZkUNyBtu+h4djBNMrDeGHOvGZ/y NliNB5MvQLtSctaWZgH4MOtKoAHLf48obRdX99gayFSYb4OrZLsuPbhJXXUHs0mDs98V E6CH7ZgmW9j+QMGa8SpRgb5VkThLga1Uny8gWacNkiMX2calggUBfhJjrLlm0mwRZmAV ozk3iSBSdymwpOi1xYhDR1fOINppGzmtAwGzcyow1H0+OY6IL6ngMSpN7a1l1sT0ozat zncMQE3oIs9RRuk+r0fs3xfm2ocVl+mdT6Z5DUWwW+y/vUrY6vXxIhQ9vYUVr/jv+pcm AdHw==
MIME-Version: 1.0
X-Received: by 10.180.104.42 with SMTP id gb10mr30173600wib.65.1406170586286; Wed, 23 Jul 2014 19:56:26 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.194.123.167 with HTTP; Wed, 23 Jul 2014 19:56:26 -0700 (PDT)
In-Reply-To: <CACsn0c=o0HFdr_qn--H8ZStQan2asbt-M60kP_70p1DCT5f0_w@mail.gmail.com>
References: <CAMm+Lwj9EPJ9v92xrkM1ceAbkWYe22fpOOBObUbUJjkk8X0dng@mail.gmail.com> <CA+Vbu7xAcKjpeqWGqkVRQeENELdMYUpZF6BNb2ntne25_dyzKg@mail.gmail.com> <CAMm+LwgDZR1_onqJ2sAEx7=rgh7=9mGYuqS36nb0T-RAr6Vgnw@mail.gmail.com> <CACsn0c=o0HFdr_qn--H8ZStQan2asbt-M60kP_70p1DCT5f0_w@mail.gmail.com>
Date: Wed, 23 Jul 2014 22:56:26 -0400
X-Google-Sender-Auth: cyy6sY8Ayftxiq3ItkE7bvMtoIQ
Message-ID: <CAMm+LwjxnGw6hgoba_V+GY8WVKh-YGpPkw1AFfn_RvoX+2OzKQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/HsFJygd3-XeCVc1mhe_BvkqHb7E
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>
Subject: Re: [Cfrg] Comparing ECC curves
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, 24 Jul 2014 02:56:29 -0000

On Wed, Jul 23, 2014 at 9:10 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Wed, Jul 23, 2014 at 4:17 PM, Phillip Hallam-Baker
> <phill@hallambaker.com> wrote:
>> On Wed, Jul 23, 2014 at 6:33 PM, Benjamin Black <b@b3k.us> wrote:
>>> On Wed, Jul 23, 2014 at 3:28 PM, Phillip Hallam-Baker
>>> <phill@hallambaker.com> wrote:
>>>>
>>>>
>>>> 3) Do we need to consider 2^192 work factor?
>>>>
>>>> I can't see any case where I am interested in a work factor of 2^192.
>>>> Either I am willing to make some concession to performance or I want
>>>> it gold plated and 2^256. I would quite like to see the 2^192 work
>>>> factor nuked.
>>>>
>>>
>>> Phillip,
>>>
>>> This was our conclusion, as well. If you haven't seen it, here's the NUMS
>>> TLS draft which only specifies the twisted Edwards curves at 128 and 256 bit
>>> security levels: http://tools.ietf.org/id/draft-black-tls-numscurves-00.txt
>>
>> Just trying to push back on the idea we need the options .. :-)
>>
>> Similarly, I am not interested in a set of curves that is
>> hyperoptimized for TLS and can't be used for S/MIME. When we were
>> discussing random curves, changing the curve was pretty much the same
>> as changing the key. Now that we are doing the close to powers of 2
>> curves with highly optimized code, changing the curve is like changing
>> to a whole new algorithm.
>>
>> As far as the code is concerned it is better to think about them as
>> choosing between ECDHE-25519 and ECDHE-256p rather than ECDHE with a
>> named curve. Changing the curve is going to select a different
>> implementation.
>>
>>
>> The end product I want from this is a set of backup public key
>> algorithms that can be made a RECOMMENDED algorithm with a view to
>> making them a MUST algorithm replacing RSA-2048 at some point in the
>> future. I want to encourage dedicated hardware support, etc. etc.
>
> Why will that happen with these curves when it didn't with the NIST
> curves vs. RSA?
> Yes, I'm aware of patent issues that used to exist, but this was an
> unforced error in
> standardization: RSA is of a similar vintage.

Several reasons.

First off, we had this philosophy that lots of algorithm choices was a
good thing. It is only recently that it is generally acknowledged that
adding stronger algorithms does not improve security. Only stopping
using weak algorithms helps matters.

So back in the mid 90s we had dozens of symmetric ciphers and RSA and
DSA and DH and it was thought to be a good thing. Then we got the idea
that there should be as few algorithms as possible, preferably one
good one. And now I am pushing for a scheme where we have one REQUIRED
and one RECOMMENDED per type of algorithm and make no other
recommendations except in unusual circumstances where a legacy
transition is in progress.

The main reason we haven't had consensus across the IETF on mandatory
to implement algorithms before is that the decisions were taken at
different times and the field moved on. So the mandatory to implement
algorithms for quite a few specs are now out of date. S/MIME requires
3DES for example. This was changed for SIP but not for mail as far as
I can see.

It is possible that some people used to enjoy algorithm discussions.
At this point I think we all realize that the discussion is necessary
but not so much fun that I want to have it repeated for each working
group.

But the main reason I want to change that practice is that when we
decided to move to AES in place of 3DES, that was a decision made
independent of any particular protocol but implementation required us
to make changes to every protocol separately. That is silly and
tedious and lots of makework for authors and the IESG.

Hence the rationale for this draft:

http://tools.ietf.org/html/draft-hallambaker-consensuscrypto-00

The idea of this is that future protocols would not make MTI choices
of algorithms, they would reference the consensus RFC and leave it at
that. If we change our idea of what necessary crypto is, the consensus
RFC would be made obsolete and replaced by a new one.

The reason for having backup algorithms is that unless we are in panic
mode (like Google starts selling a Quantum Computer just for S&G) the
pattern should be that the new REQUIRED algorithm is a previous
RECOMMENDED algorithm. Since they are backup algorithms there is a
requirement that they be constructed in a distinctly different fashion
(e.g. SHA-3 is a logical backup to SHA-2 because it is spongeworthy).
The backups also need to be distinctly stronger.

I will also note that it looks like we now have a pretty strong
primary and backup for hash functions and MACs and seem to be
approaching consensus on public key (RSA plus ECC exact scheme to be
decided). That leaves a gap for backup encryption algorithm.