Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

David McGrew <> Mon, 21 July 2014 11:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27D3E1B2D4A for <>; Mon, 21 Jul 2014 04:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KIc7sWwcFqjf for <>; Mon, 21 Jul 2014 04:45:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99E7C1B2DA4 for <>; Mon, 21 Jul 2014 04:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5439; q=dns/txt; s=iport; t=1405943145; x=1407152745; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6wVxGuNhjo/mxVy7rpdPLzC/xHWVjvwS1ma+oOidtrw=; b=OumenAdcwdGavOGa76+easL3DnBtFNgOeUzN3wYuuN3vBkUHb3K9bsSf Amkhb5vbllAzwhmEENM7v4lfGXiw+7CRcfIkCc09Jp8PkFGKxGZdehjCc hV4fh/kDtvjtzTEd3jYRG+SnQg09bMjvwYmrEdk/sdc17NcQkZAOKjmOW 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAB/8zFOtJV2R/2dsb2JhbABZgw5SxXYKh0UBgRoWdoQEAQEDAQEBAQtXCQsFCwtGJzAGEwkSiB8IDb5mF4l+gxAtgTgBJDMHgy6BGAWbJZQvg2AhL4EDAR8
X-IronPort-AV: E=Sophos;i="5.01,700,1400025600"; d="scan'208";a="62642903"
Received: from ([]) by with ESMTP; 21 Jul 2014 11:45:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s6LBjfMa014215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 11:45:42 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: David McGrew <>
In-Reply-To: <>
Date: Mon, 21 Jul 2014 07:45:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Simon Josefsson <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>
Subject: Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Jul 2014 11:45:50 -0000

Hi Simon,

On Jul 16, 2014, at 5:39 PM, Simon Josefsson <> wrote:

> I'm reviewing the selection criteria.  Some of the requirements are
> rather fine-grained and poorly justified, and appear to limit the search
> space.  If taken literally, I believe they exclude some good candidates
> and steer the selection into a rather small field of available options.
> I'm fine with R1-R3.
> "Paterson, Kenny" <> writes:
>> Intellectual Property
>>   R4.  Required: available worldwide under reasonable and well
>>   understood licensing terms [1]
>>   R5.  Desired: available worldwide under royalty-free licensing
>>   terms [1]
> I believe non-royalty-free licensing terms is a nonstarter.  I suggest
> collapsing this into:
> R4'. Required: available for worldwide implementation (by both
>     proprietary and free open source software) and use under well
>     understood and royalty-free licensing terms
>> Interoperability
>>   R6.  Desired: can be used with current software implementations
>>   (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]
>>   R7.  Desired: can be used within current ECC standards of TLS,
>>   PKIX, SSH, and IKE [4]
> I do not see why these are desirable properties, so I disagree they
> should be a selection criteria.  

These properties are valuable because 1) they lower the cost of adopting the new curves, thus making adoption faster or more likely, 2) they simplify (at least some) implementations by allowing them to avoid implementing an additional ECC scheme and a protocol interface for it.    Many people do see these requirements as important; this was Russ Housley’s point at the mic at the last TLS WG, and I agree with him.   Simplicity of design and implementation is a really important point that we need to not lose sight of.   Less code, fewer bugs.

I concede that these properties do limit the design space, which is why they should be “desired” rather than required.    In my opinion, anyway.

What is most important is that people understand which criteria are met by a given ECC scheme, so that they understand what they are actually getting. 

> These properties restricts the search
> space.  I would prefer if the CFRG are at liberty to recommend the best
> alternative even if it is clearly not re-usable in existing software or
> standards.  I would go even further saying that one of the reasons for
> doing this excercise is that the existing software and standards are not
> sufficient.
> On the topic of interoperability, I would propose to add the following,
> to me, more important property:
> Rx. Desired: either a clear algorithm description exists (with clarity
> on byte-ordering etc) or multiple interoperable implementations are
> available.

I agree that this is a good criteria, though I will note that multiple interoperable implementations are no substitute for a clear algorithm description.  

> If some alternative does not appear to be sufficiently specified or
> widely implemented, the CFRG could take on driving a document to clarify
> the solution.
>> Security
>>   R8.  Required: amenable to constant-time implementations, to avoid
>>   side channel attacks [2]
>>   R9.  Required: resist twist attacks [2]
>>   R10.  Required: curve parameters should have good provenance;
>>   random curves should be provably pseudorandom [5]
>>   R11.  Desired for key exchange: resist invalid curve attacks [2];
>>   note that complete addition laws help and are thus desirable [2].
>>   (Note that the use of ephemeral keys also resist such attacks.)
> Instead of R8-R11, I suggest to summarize this more generally

I disagree.   These requirements should be kept separate because they allow us to differentiate between different proposed ECC schemes.

> as:
> R8'. Required: the solution should be secure against reasonable and
> well-understood threats, including (but not limited to and necessarily
> not all of) brute-force, side-channel, invalid-curve, twist attacks, or
> maliciously chosen curve parameters.
> Designing against security threats is a balance, and I would say that
> there are no perfect solutions.  Every solution will have some area
> where they perform less well compared to some other solution.  I believe
> the overall choice(s) should reflect well-balanced alternatives with
> strong advantages and some understood disadvantages.
>>   R12.  Required for PAKE: indistinguishability of curve points from
>>   random strings [2]
> I do not see why this is a desirable property for TLS, or other IETF
> areas, so I disagree it should be a requirement.

Yeah, I take your point.   In the context of TLS, perhaps this should be worded as “desired: indistinguishability of curve points from random strings, so that the curves could also be used in PAKE protocols”.    This would allow for implementation and specification re-use for PAKE, which could make a PAKE easier to adopt.  


> /Simon
> _______________________________________________
> Cfrg mailing list