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

Benjamin Black <b@b3k.us> Sat, 19 July 2014 22:43 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 18F531B2A87 for <cfrg@ietfa.amsl.com>; Sat, 19 Jul 2014 15:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 GM_Stu6EaCaA for <cfrg@ietfa.amsl.com>; Sat, 19 Jul 2014 15:42:58 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EF91B2A7D for <cfrg@irtf.org>; Sat, 19 Jul 2014 15:42:58 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id d1so2397920wiv.3 for <cfrg@irtf.org>; Sat, 19 Jul 2014 15:42:56 -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=bYK+Gy0Aot1tqJ6wQzE7fzwZSuTLNN3Co2sU2KdoOHg=; b=ZMawhWv7iyHOgy504kFY5001E3AMNXx2pVG7sco0VgE9x2J1Rc5GZMnSSPC25d/njV KzUwvlk/Zp6fbsqZfEqSM5sFeMOUWmAO/mjQf1PzvBdAir/KKRWykzQXu6piQ+8bcYSL zXiMbfiK2vN1CVCOuyEN56/82iFiE3wRiWIqF0saOpkIz2vEBe5yHvTiCMJm5n0IbhVG //cMsMWJNeHm91QdAzQYAO1bCLFpXcAz/+a3Ec8vVT3A2hr3/ShPcCbBTgFGQrhct9Fd ihyR87bMx+WHPm17dwjOXzE9OgGOgNq5zVyg5DIxY+B5oiDenN77Qx9y0FkEtxbueSwr 2vtQ==
X-Gm-Message-State: ALoCoQmXUWdNQ8zH8kW6sOJ4RUacPIcDMmrFn71h1uuWaQYA5FgDvp34M10KCNQydN9pTv/xdAph
X-Received: by 10.194.60.35 with SMTP id e3mr8515602wjr.12.1405809776822; Sat, 19 Jul 2014 15:42:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.44.138 with HTTP; Sat, 19 Jul 2014 15:42:36 -0700 (PDT)
In-Reply-To: <E600EB81-2EED-4B84-A9F2-38B27397A497@cisco.com>
References: <CFE9F2DE.26E5A%kenny.paterson@rhul.ac.uk> <CACsn0cnxswoPzS8VFRXTO=MD+L+ezckKmWwhi26-1bJqNw5YCQ@mail.gmail.com> <8303B8FE-DE35-4567-893F-A61606890DFF@cisco.com> <CA+Vbu7zHQf0LAdnwffaBJGV5emFLbz5BM=1ZX7dYuh4A1iPL8w@mail.gmail.com> <E600EB81-2EED-4B84-A9F2-38B27397A497@cisco.com>
From: Benjamin Black <b@b3k.us>
Date: Sat, 19 Jul 2014 15:42:36 -0700
Message-ID: <CA+Vbu7xOnpHO8-U+f6r_30TfPkOQ5Sz1kp9vf4eAQnXTkG-qwA@mail.gmail.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b86e8ba5ea57704fe939885
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XARKZ5EhtqKQJHzdwQmqwgBNGwY
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic 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: Sat, 19 Jul 2014 22:43:02 -0000

"The CFRG has the cryptographic expertise to determine what pairings are
appropriate."

As do a number of others, including other leaders of the TLS working group.
I refer you again to RFC5289 and again request an explanation for this
contradicting of all prior practice in the TLS working group.

"As a practical matter 128-bith strength ciphers are sufficient for most
current deployments."

For higher security requirements, as a practical matter for most
deployments, 256-bit symmetric ciphers are combined with 192-bit strength
curves. I would also suggest you are making an incorrect assumption in
saying 128-bit is sufficient. I think you'll find some very large online
services defaulting to 256-bit ciphers. So, based on your own metric of
current deployment, with which I agree, the required curve strengths are
128 and 192. If you wish to apply a different metric, and especially if you
wish to apply different metrics for the different strengths, then I'd ask
that you bring something rather stronger to the table as justification.

"From what I understand there are currently curves families under
consideration which do not currently the higher strength key size defined."

This is irrelevant! We are talking about requirements for TLS, not
immediately available curves we could adopt if we squint a bit and ignore
the enormous overhead inherent in migrating to them. If they don't have the
higher strength defined, they are not viable candidates. That's how this
process works. If you instead insist on wrapping the requirements around
the curves then I am unclear on the point of this exercise, at least on an
engineering level.

"If the CFRG determines these curves have significant enough advantages it
could make this recommendation while the details of the higher strength
curves are being worked out.  However, the CFRG is not obliged to wait."

Once again, this is absolutely contrary to all prior work in TLS and almost
all work across IETF. It implies that every single curve at every strength
will need at least one new draft and possibly more since there is
discussion of allowing new signature schemes for no apparent reason. What
is the rush that requires this highly unusual direction?


Ben


On Fri, Jul 18, 2014 at 1:59 PM, Joseph Salowey (jsalowey) <
jsalowey@cisco.com>; wrote:

>
>  On Jul 17, 2014, at 11:03 PM, Benjamin Black <b@b3k.us>; wrote:
>
>  "TLS supports 256-bit symmetric key ciphers and we want to have
> recommended curves to match this key strength.  We leave it up to the CFRG
> to determine what ECC key strengths are appropriate above 128-bit symmetric
> key strength."
>
>  Can you clarify why this is the case? TLS already has suites with
> 256-bit symmetric ciphers and they are paired with 192-bit security level
> components, including curves [1]. I can see arguments in favor of either
> 192 or 256, but I don't see how this is now a CFRG decision.
>
>
>  [Joe]  The CFRG has the cryptographic expertise to determine what
> pairings are appropriate.
>
>  "It is also not necessary that the recommendation for higher strength
> curves be delivered at the same time, it would be OK to deliver a
> recommendation for the 128-bit curves before the higher strength curves."
>
>  Can you clarify why this is the case? I'm not aware of any other
> standardization effort that has done this and see no reason for it.
>
>
>  [Joe]  As a practical matter 128-bith strength ciphers are sufficient
> for most current deployments.  From what I understand there are currently
> curves families under consideration which do not currently the higher
> strength key size defined.  If the CFRG determines these curves have
> significant enough advantages it could make this recommendation while the
> details of the higher strength curves are being worked out.  However, the
> CFRG is not obliged to wait.
>
>
>  Ben
>
>  [1] RFC5289
>
>
> On Wed, Jul 16, 2014 at 8:35 AM, Joseph Salowey (jsalowey) <
> jsalowey@cisco.com>; wrote:
>
>>
>> On Jul 14, 2014, at 6:11 PM, Watson Ladd <watsonbladd@gmail.com>; wrote:
>>
>>  > On Jul 14, 2014 12:49 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>;
>> wrote:
>> >>
>> >> Dear CFRG,
>> >>
>> >> CFRG has received a formal request from the TLS Working Group for
>> >> recommendations for new elliptic curves. Specifically, the TLS WG would
>> >> like CFRG to recommend:
>> >>
>> >> - Curves suitable for both key establishment and digital signature
>> >>  (though the same curves need not be used for both purposes).
>> >>
>> >> - One proposed curve or set of curves at the following security
>> >>  levels: 128-bit (~256-bit curve) and 256-bit (~512 bit curve).
>> >>  192-bit security is optional.
>> >
>> > I would like these to be taken as minimums. There is no reason
>> > Curve4417 should not be used for 192 bit security
>> > or Goldilocks448 if performance is acceptable.
>> >
>> > I am not sure that 512 bits is needed: the NSA only uses P-384 for Top
>> > Secret data. Perhaps this is an area where the
>> > TLS WG can do some more thinking about what they want to see.
>> >
>>
>>  [Joe] We've received a few comments about this offline so I want to
>> clarify on desired strengths. TLS supports 256-bit symmetric key ciphers
>> and we want to have recommended curves to match this key strength.  We
>> leave it up to the CFRG to determine what ECC key strengths are appropriate
>> above 128-bit symmetric key strength.  It is also not necessary that the
>> recommendation for higher strength curves be delivered at the same time, it
>> would be OK to deliver a recommendation for the 128-bit curves before the
>> higher strength curves.
>>
>> >>
>> >> Note that these curves are not intended to supplant current curves in
>> >> widespread use, but rather to supplement them. Full details of the
>> request
>> >> can be found in the e-mail from the TLS WG chairs below.
>> >>
>> >> The CFRG chairs will coordinate a response to this request from the
>> CFRG
>> >> readership. Ideally we will reach a rough consensus through discussion
>> on
>> >> the
>> >> list and at the upcoming IETF 90 meeting in Toronto. While no deadline
>> is
>> >> set for our response to the TLS WG, we should aim to have one ready
>> within
>> >> 2 months.
>> >>
>> >> We regard this as a major work item for CFRG and one where CFRG can
>> >> provide real value to the TLS WG and the IETF more widely. So we
>> encourage
>> >> (and indeed request) active participation from the widest set of
>> >> participants on this project.
>> >>
>> >> As a first step, we propose to discuss the requirements for new curves
>> for
>> >> a period of 2 weeks. Using an agreed set of requirements, in a second
>> >> step, we will then evaluate different curve proposals (including extant
>> >> proposals and any emerging ones) for a period of 4 weeks. In a final
>> >> period of 2 weeks, we will produce a proposal for the TLS WG and seek
>> >> consensus on it.
>> >
>> > What should a proposal look like? A family of similar curves, one for
>> > each length?
>> > How much implementation should be done? Making very fast
>> > implementations can require a lot of coding,
>> > but I think we know about how fast prime shapes will be, and curve
>> > shape+prime shape gives you
>> > everything but the TLC factor.
>> >
>> >>
>> >>
>> >> The first step, running for 2 weeks, begins here.
>> >>
>> >> A starting point for requirements can be found in David McGrew's recent
>> >> CFRG post
>> >> (http://www.ietf.org/mail-archive/web/cfrg/current/msg04461.html) and
>> >> reproduced here:
>> >>
>> >> ----
>> >>
>> >> Simplicity
>> >>
>> >>   R1.  Desired: easy to understand and implement [1]
>> >>
>> >> Efficiency
>> >>
>> >>   R2.  Required: amenable to compact implementations and fast
>> >>   implementations, across both small and large processors [1]
>> >>
>> >>   R3.  Desired: re-use components between signatures and key exchange
>> >>   algorithms [3]
>> >
>> > How about code size for R3 to make it more amenable to argument?
>> >
>> >>
>> >> 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 would make R5 a requirement. Royalties are a nonstarter for many
>> users.
>> >
>> >>
>> >> 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]
>> >
>> > These desiderata are worthwhile, but implementors have signalled they
>> > are willing to make
>> > large changes for performance.
>> >
>> >>
>> >> Security
>> >>
>> >>   R8.  Required: amenable to constant-time implementations, to avoid
>> >>   side channel attacks [2]
>> >>
>> >>   R9.  Required: resist twist attacks [2]
>> >
>> > I don't like R9: twist attacks are only an issue with algorithms that
>> > work on the compressed form. It just feels different.
>> > Perhaps the requirement should be that implementations that miss
>> > checks avoid being completely insecure.
>> >>
>> >>   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.)
>> >
>> > I feel this should be folded into an edited R9.
>> >>
>> >>   R12.  Required for PAKE: indistinguishability of curve points from
>> >>   random strings [2]
>> >
>> > Mike Hamburg will know better than I, but my vague recollection is
>> > that Elligator 2 worked for everything.
>> >>
>> >> Footnotes:
>> >>
>> >>   [1] Original criteria set out for the Advanced Encryption Standard,
>> >>       which is equally applicable to ECC.  National Institute of
>> >>       Standards and Technology (NIST) of the United States, 1998.
>> >>
>> >>   [2] Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe
>> >>       curves for elliptic-curve cryptography.
>> >>       http://safecurves.cr.yp.to <http://safecurves.cr.yp.to/>
>> >> <http://safecurves.cr.yp.to/>;, accessed
>> >> April 2014.
>> >>
>> >>   [3] Criteria identified by David McGrew, 2014.
>> >>
>> >>   [4] Criteria identified by Russ Housley, TLS WG meeting at IETF89.
>> >>
>> >>   [5] Criteria widely acknowledged on CFRG email list during 2014.
>> >>
>> >> ----
>> >>
>> >>
>> >> Our first request, then, is that you consider these requirements, and
>> >> provide your views on their appropriateness, completeness, and
>> individual
>> >> classifications (required/desired). We will continue that discussion
>> for 2
>> >> weeks, until the end of the IETF meeting in Toronto. The chairs will
>> then
>> >> compile a consensus-based list of requirements of the above form, after
>> >> which we will move to the second step.
>> >>
>> >> We thank you in advance for your participation in this important task.
>> >>
>> >> Regards
>> >>
>> >> Alexei, Kenny and Kevin (CFRG co-chairs)
>> >>
>> >>
>> >>
>> >>
>> >> On 11/07/2014 05:44, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>;
>> >> wrote:
>> >>
>> >>> CFRG Chairs and Security ADs,
>> >>>
>> >>> TLS WG would like to formally request that the
>> >>> CFRG make a recommendation for new ECC group support for TLS
>> >>> and other similar applications. Specifically, we request that CFRG
>> >>> recommend the following:
>> >>>
>> >>> - Curves suitable for both key establishment and digital signature
>> >>> (though the same curves need not be used for both purposes).
>> >>>
>> >>> - One proposed curve or set of curves at the following security
>> >>> levels: 128-bit (~256-bit curvee) and 256-bit (~512 bit curve).
>> >>> 192-bit security is optional.
>> >>>
>> >>> If the same curves are used for key establishment and signature, this
>> >>> would be a recommendation for two curves.  If different curves are
>> >>> used, this would be a recommendation for four curves.
>> >>>
>> >>> In addition to a recommendation, we also request that the CFRG provide
>> >>> a technical rationale for their selection.
>> >>>
>> >>> If the CFRG does not feel comfortable making a single set of
>> >>> selections, we propose that they select a small number of potential
>> >>> choices with a detailed technical analysis of the advantages and
>> >>> disadvantages of each selection and that the Security ADs sponsor a
>> >>> process (perhaps via SAAG) to narrow it down to the specification
>> >>> above.
>> >>>
>> >>> For clarity, we are not currently requesting that CFRG replace or
>> >>> profile the existing curves in RFC4492 and RFC 7027, although we are
>> >>> also not ruling out such an effort in the future. The current request
>> >>> is for a new set of curves to complement the existing ones.
>> >>>
>> >>> Please reach out to us if this is unclear or further information is
>> >>> required.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> TLS Chairs
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Cfrg mailing list
>> >> Cfrg@irtf.org
>> >> http://www.irtf.org/mailman/listinfo/cfrg
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > Cfrg@irtf.org
>> > http://www.irtf.org/mailman/listinfo/cfrg
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
>