Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Eric Rescorla <ekr@rtfm.com> Thu, 26 June 2014 22:10 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080681B2F02 for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 15:10:58 -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 Qrh98t5j6fjo for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 15:10:54 -0700 (PDT)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ECA1B2EF5 for <tls@ietf.org>; Thu, 26 Jun 2014 15:10:54 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id y10so4463230wgg.32 for <tls@ietf.org>; Thu, 26 Jun 2014 15:10:53 -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=21xGl+VqLlh40mBy1Oj38W7TU6th+oABrm785hp3hXA=; b=lLnez6xyGMoFXDVlbwo39k6nVGuCavQIR3ys0EKnFFEzV2S0beOVOeLmH1m891eY5N 61y9erFPYYEZChenqaOkmM+gWkVZG12+LolVpj10bfGMjAjdjAd5Z2snvDXgp1jX2J7Q NODLT0MlVn1G3bvyNsYtG3/s1LCkKf8PLes1xLp/5mNAOL35UyIRQ+y97Pu9StY+z6ge /yzsbjlJbL0OTENsHdNFFjKiy8KTp5lsAyM7jNdS/dqsLUj05LNR2L4dKB+skpv/vgHu 9+X5fMtDihLT3ZdULyiJNU4cAjy3mrKCajL9CXHl109zdFvDm4flGYycQ8e455Wf+sYV CvWA==
X-Gm-Message-State: ALoCoQnmIOrmrjOaQOfOkuwVpodcYsj7zS+jHQgM3C/cyr9uZb++3zVXurqYz1KBZLLLtIDxLhuA
X-Received: by 10.194.110.10 with SMTP id hw10mr21188172wjb.81.1403820652899; Thu, 26 Jun 2014 15:10:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 15:10:12 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:e88c:a4b4:d3a:6b6a]
In-Reply-To: <53AC97B8.2080909@nthpermutation.com>
References: <53AC97B8.2080909@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 26 Jun 2014 15:10:12 -0700
Message-ID: <CABcZeBN5uY4bteXW=OFC1z3ANoSC8AqxG6E6artdOKPF=VxdJg@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary="089e010d870c584bbe04fcc4771a"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dhdYwXDqrhrioJ5kNYGoej3XsL4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 22:10:58 -0000

On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

> There's been a small but vocal minority agitating for the adoption of
> Curve25519 for use in TLS (and other IETF protocols).  As the discussion
> has gone on, what I haven't seen is compelling evidence that this
> technology has been vetted sufficiently that it would meet the "Best
> Commercial Practices" threshold for safe harbor status for encryption.  It
> may eventually get there, but for at least the next few (5-10??) years, I
> would expect businesses to avoid the use in privacy sensitive, or
> financially sensitive operations.
>
> There are also possible IPR issues, definite infrastructure issues (e.g.
> no off the shelf, commercial hardware or software AFAIK), documentation
> issues (not the base curve, but how to incorporate curve data into
> certificates and other protocol messages, and the fact it's key agreement
> only (vs the current EC curves which can be used for both signature and
> agreement).  A long list of items that probably, but not definitely, can be
> resolved.
>
> AFACT, one of the main reasons for looking at Curve25519 (possibly more
> important than performance or security) is that there is a fear that the US
> Government has placed trapdoors in the current set of curves (NIST P256,
> P384, P521 etc).   The argument against the "provably random" creation
> claim with respect to those curves appears to be that many "seed" values
> could have been generated to generate curve parameters and those curves
> tested to find "weak" curves of a particular flavor and the seeds for weak
> curves retained.  In other words, we don't know how the seed values were
> generated and it could be nefarious.  I haven't as yet found any argument
> against the generation process, nor specifically against the elliptic curve
> math.
>
> Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the
> various ISO documents is pretty much identical, instead of throwing away
> all that implementation and standardization, how about we just generate new
> curves:
>

[Snip]
I'm cutting here because I would like to encourage WG members to
focus on the general merits of this suggestion (or lack thereof, depending
on your perspective) rather than on the specific details of the procedure
Mike has proposed. I think it's clear that we could develop a procedure
for producing verifiably random seeds, but let's try to figure out first
whether that's a good idea before we worry about how to do it.

Also, this seems like a bigger topic than TLS. Perhaps the
AD should sponsor a discussion in SAAG?

-Ekr