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

From: Michael StJohns <[email-masked]>
Date: Thu, 26 Jun 2014 17:59:20 -0400

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:

1) 20 organizations publicly contribute random/pseudo-random strings of 
1kbits - they get to decide exactly which bits to send.
1a) discard any of these with detectable bias.
2) Randomly select 10 sets of contributed bits from those remaining 
(using public randomness sources to select those to be retained).
3) Concatenate the bits in a random order (using public randomness 
sources such as stock prices etc to select the order).
4) Run the concatenated data through an entropy extraction process (e.g. 
hash, hmac, other PRF) to produce a seed value of sufficient length. (or 
seed values if all the curves come from this one pass).
5) Generate the curve data and generator points from the seed.
6) Assign IETF OIDs to each curve generated this way.
7) Permanently record ALL the data used to generate the curves so we 
don't have future conspiracy theories.

For most of libraries and hardware devices with which I work, the curve 
data is pretty much static configuration (external table referenced by 
OID) or compilation (ditto but compiled in), or provided as a library 
argument and most libraries have a mechanism to insert or use new curves 
fairly easily - at least within the same family.  I'd recommend that we 
generate curves equivalent in strength to the current NIST curves in all 
of prime, binary and koblitz flavors.

Mike

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 26 Jun 2014 22:08:06 +0000

+1

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Michael StJohns [mailto:[email-masked]]
Sent: Thursday, June 26, 2014 05:59 PM
To: [email-masked] <[email-masked]>
Subject: [TLS] On Curve25519 and other possibilities  (e.g. ietf256p, ietf384p, ietf521p, 

Mike

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jun 2014 15:10:12 -0700

On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns <[email-masked]>
wrote:

> 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.
>
> 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.
>
> 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

---

From: Hanno Böck <[email-masked]>
Date: Fri, 27 Jun 2014 00:12:15 +0200

On Thu, 26 Jun 2014 17:59:20 -0400
Michael StJohns <[email-masked]> wrote:

> 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.

I think another major argument against NIST curves was that it's hard
to implement them in constant time. DJB had this and other issues
explained in a blog post [1].

As we saw a lot of timing attacks lately (Lucky Thirteen, Comeback of
Bleichenbacher attack in Java and OpenSSL) and I'd expect we'll see
more of that I think timing safety should be a crucial feature of all
future TLS algorithms.

[1] http://blog.cr.yp.to/20140323-ecdsa.html

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jun 2014 15:14:04 -0700

> AD should sponsor a discussion in SAAG?

I think that this is more relevant right here and now.  TLS has enough
to handle already.  I think that we might want to start by finding a
more appropriate venue.  SAAG might be a good place to start.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 26 Jun 2014 22:20:27 +0000

IMHO verifiably random generation of curves is desirable.

MIT LL Root CA:

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, June 26, 2014 06:10 PM
To: Michael StJohns <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns <[email-masked]<mailto:[email-masked]>> 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]

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Thu, 26 Jun 2014 15:22:03 -0700

On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns <[email-masked]> wrote:
> 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.

I assume that such organisations are not going to adopt any newer
curves either then.

> There are also possible IPR issues

I don't believe that there's any basis to this (beyond the level of
any other ECC).

> definite infrastructure issues (e.g. no
> off the shelf, commercial hardware or software AFAIK)

There are plenty of software implementations with a higher general
quality than any of the NIST curves, although certainly there isn't
any hardware. However, hardware support is the result of demand and
time. There's no hardware support for any curves that the IETF might
come up with either.

> documentation issues
> (not the base curve, but how to incorporate curve data into certificates and
> other protocol messages

Again, I feel that this applies equally to anything new.

> and the fact it's key agreement only (vs the
> current EC curves which can be used for both signature and agreement).

The curve is not key-agreement only. Many implementations provide only
a Montgomery ladder, which does only provide key agreement, but it
works fine for signatures too: http://ed25519.cr.yp.to/

(In fact, I'm not sure if any elliptic curve could be key-agreement
only. Signature schemes fall out of any suitable group, no?)

> P384, P521 etc).

Although some certainly subscribe to that, my main motivation for
moving away from P-{256,384} is that they simply aren't good curves.
They are difficult to implement correctly and have many pitfalls.
Elliptic curve design has advanced significantly since then.

> various ISO documents is pretty much identical, instead of throwing away all
> that implementation and standardization, how about we just generate new
> curves:

Let's just take is as read that new parameters (with the same field?)
could be generated. I'd suggest that the approach in [1] would be
better, but that's not important.

[1] https://research.microsoft.com/apps/pubs/default.aspx?id=209303

> For most of libraries and hardware devices with which I work, the curve data
> is pretty much static configuration (external table referenced by OID) or
> compilation (ditto but compiled in), or provided as a library argument and
> most libraries have a mechanism to insert or use new curves fairly easily -
> at least within the same family.

In my experience, the cost of a change is mostly fixed. I believe that
the development work that goes into the change is small compared to
the effort to update all the software.

Even if that's not true, we would have to be very careful to
understand the range of easy reconfiguration of these libraries. Do
they specialise the field reduction? (Probably) Thus that would be
fixed. I assume that a=-3 is fixed too. They might be other
limitations in code that would be hard to discover, meaning that the
cost of implementing the change ends up being about the same as any
new curve anyway.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Jun 2014 22:24:43 +0000

> whether that's a good idea before we worry about how to do it.

Note, that RedHat and (probably some others) truncate the curve
support in OpenSSL to just P-256, P-384 and P-521 for IPR reasons.
I see little reason to expect that they would include implementations
of any of the new proposed curves.

The new curves would also suffer from all the ECDSA defects noted
by DJB and would not have the performance advantages of Edwards
curves.

So I see little value in a new batch of essentially the same type
of curves.  Just more bloat in the client HELLO listing curves
nobody has or is willing to use.

If we have an opportunity to advance the state of the art, and use
(subject to CFRG review, ...) new EC techniques based on lessons
learned after ECDSA, that are more performant and less prone to
implementation errors, then there is a good reason to add new
curves.  They might still not get adopted until all the EC patents
expire, but at least eventually they move things forward, not
sideways.

Just adding more of the same old stuff, but with a different proof
of randomness does not seem compelling.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 26 Jun 2014 18:24:51 -0700

> businesses to avoid the use in privacy sensitive, or financially sensitive

And RC4 meets them? The fact is that we understand ECC very, very
well: the issues involved with changing curves are akin to those in
changing primes in Diffie-Hellman: most choices are terrible, but they
are easy to avoid. Furthermore, TLS has many options that are
little-used: I don't see the harm with adding another curve,
particularly when it will not be little used.

>
> There are also possible IPR issues, definite infrastructure issues (e.g. no
> off the shelf, commercial hardware or software AFAIK), documentation issues
> 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.

IPR issues: Montgomery curves were developed in 1985. Any patents
would have expired in 2005.

The key agreement only issue doesn't affect the currently envisioned
use as a faster and more secure key
negotiation mechanism. There is a signature variant Ed25519, but yes,
this cannot go into x509 certificates right now,
and likely due to legacy software, for a long time.

As for software, there are many mature, well tested, and secure implementations.
> 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

Other than slow speed, exceptional cases, and primes that are painful
on 64 bit processors (P256 specific)
there are no problems. Oh, and the lack of point validation in some
widely deployed software.

> 2) Randomly select 10 sets of contributed bits from those remaining (using
> public randomness sources to select those to be retained).
> 3) Concatenate the bits in a random order (using public randomness sources
> such as stock prices etc to select the order).
> 7) Permanently record ALL the data used to generate the curves so we don't
> have future conspiracy theories.

What does this get us that Brainpool did not?

> at least within the same family.  I'd recommend that we generate curves
> equivalent in strength to the current NIST curves in all of prime, binary
> and koblitz flavors.

You do realize there is only koblitz curve for each binary field size, right?
For prime koblitz it's a similar story.

Why? What do these curves have to offer above Brainpool or NIST?
There's a strong case for including Curve25519 for performance and
implementation quality reasons. For another Weierstrass curve, those
don't exist.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 26 Jun 2014 21:50:43 -0400

I don’t find Mike’s concerns compelling; most of them have been (to me) adequately discounted by Adam and Victor’s posts.  For further info on patents and such, see http://cr.yp.to/ecdh/patents.html.

Most importantly, IMHO, is at the Spring interim meeting of the CFRG, it was decided to recommend Curve25519  for use in IETF protocols; see
http://www.ietf.org/mail-archive/web/cfrg/current/msg04505.html

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]<mailto:[email-masked]>; Twitter: RichSalz

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 27 Jun 2014 07:46:38 +0100

On 26/06/2014 22:59, Michael StJohns wrote:

> There's been a small but vocal minority agitating for the adoption
> of Curve25519 for use in TLS (and other IETF protocols).

CFRG have selected Curve25519 as the preferred elliptic curve for use
in IETF protocols, as Rich has pointed out.

That is because it is very, very good: it is 8 years old, extremely
fast, and simpler and faster to implement in constant-time, with _far_
fewer special cases, than any Weierstrass-form curve.

> possible IPR issues

"Total number of IPR disclosures found: 0"

As per IETF/IRTF IPR policy, kindly _reference_ any relevant IPR you
are aware of.

To the best of my knowledge, Curve25519 is patent-free: all relevant
patents have expired. No-one has stated anything to the contrary, as
far as I can see, including those at Certicom who are on CFRG (who
would have had to have raised anything relevant, I gather?).

> definite infrastructure issues (e.g. no off the shelf, commercial 
> hardware or software AFAIK),

Please note the extremely liberal license of the very high quality
open-source software implementation in NaCl. It is public domain: you
can take it and use it right now if you want, with zero IPR issues.

Hardware implementations always lag new technologies: ARMv8 only just
got SHA-256, and Intel and AMD don't have anything which specifically
accelerates any crypto except AES.

This is alright, as the software performance of Curve25519 is
extraordinarily good.

It is of course unreasonable to demand implementations exist _before_
specifications. However, adoption has already begun (OpenSSH, Tor,
OpenBSD, Chromium), and perhaps in some places that may surprise you
(the Apple iPhone!).

> documentation issues (not the base curve, but how to incorporate
> curve data into certificates

Curve25519 can be used with signatures, in twisted Edwards form:
please see Ed25519. That has not yet been codified with CFRG or the
PKIX WG, as far as I know, but exists and works very well (OpenBSD
uses it, for example): discussion is still ongoing about details, and
probably needs a refresh/reminder over there.

The use of Curve25519 with ECDHE is covered by the josefsson draft, as
you may remember, back from September 2013:
<https://tools.ietf.org/html/draft-josefsson-tls-curve25519-05>

> [Re: potential trapdoors in NIST curves]

Already very widely discussed, but obviously not relevant to Curve25519.

I know of no backdoors in NIST P256 (secp256r1) or P384 (secp384r1);
but yes, the possibility one exists is alarming, and investigations
into the curve-generation process still leave things remarkably murky.

> how about we just generate new curves:

With blackjack and hookers? :-)

Perhaps the paper at <http://safecurves.cr.yp.to/bada55.html> would be
of interest to you. I would recommend reading it before proceeding any
further with that discussion, especially down to the "Notes on
terminology and security" section.

Brainpool has already generated a set of 'random' primes, but random
primes are extremely slow to implement - and in the case of Brainpool,
the 256-bit curve has extremely unfortunate lack of twist security, so
any implementation that tries to skip validation is in really big trouble.

By adopting Curve25519, we have the opportunity to take advantage of
what we've learned about EC _since_ the engineers at Certicom
generated the NIST curves.

Obviously, I'm part of the 'vocal minority' here, as I'm planning to
use it very soon, because it makes ECDHE both secure and really,
really fast - and that's a huge win for both TLS 1.2 & TLS 1.3!

- -- 
/akr

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Jun 2014 10:13:40 +0200

It might be worth noting that many boards have dedicated chips for
cryptographic operations and even entire protocol stacks.

This, however, does not mean that they are hardware implementations.
They are software implementations running on separate chips. For
embedded systems the benefit of such approach is that the vendor of the
board can make the life of the embedded developer easier since they do
not have to search for a library and the runtime of the code can be
better controlled (particularly relevant if there are some real-time
related requirements to consider).

Based on the discussions at the IRTF interim meeting a little while ago
I took the Curve25519 code and ported it to mbed (the online development
platform ARM provides, see https://mbed.org).

I wanted to know how long it takes to generate key pairs since this is
one of the most performance-demanding operations. To my surprise it was
rather fast:

 - 0.278821 seconds for generating a Curve25519 key pair on a Cortex M0
(FRDM-KL25Z, 48MHz)
https://mbed.org/handbook/mbed-FRDM-KL25Z

 - 0.047394 seconds for generating a Curve25519 key pair on a Cortex M3
(LPC1768, 96MHz)
https://mbed.org/platforms/mbed-LPC1768/

(Note that I did not include the calculation of the random numbers in
those numbers since it will depend on a variety of factors, including
the hardware capabilities of the used board.)

These are processors used in the Internet of Things environment.

I will have to do more tests using different processors and different
curves [but I have to start somewhere].

> accelerates any crypto except AES.

Ciao
Hannes

---

From: Joachim Strömbergson <[email-masked]>
Date: Fri, 27 Jun 2014 10:21:00 +0200

Aloha!

Hannes Tschofenig wrote:
> Based on the discussions at the IRTF interim meeting a little while
> ago I took the Curve25519 code and ported it to mbed (the online
> development platform ARM provides, see https://mbed.org).
> 
> I wanted to know how long it takes to generate key pairs since this
> is one of the most performance-demanding operations. To my surprise
> it was rather fast:
> 
> - 0.278821 seconds for generating a Curve25519 key pair on a Cortex
> M0 (FRDM-KL25Z, 48MHz) https://mbed.org/handbook/mbed-FRDM-KL25Z
> 
> - 0.047394 seconds for generating a Curve25519 key pair on a Cortex
> M3 (LPC1768, 96MHz) https://mbed.org/platforms/mbed-LPC1768/

Great work and information! Have you done a write-up of the results? I'm
very interested in info on the code size and data memory during operation.

> (Note that I did not include the calculation of the random numbers
> in those numbers since it will depend on a variety of factors,
> including the hardware capabilities of the used board.)

So how did you do the random generation? Fixed values or some other
mechanism?

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jun 2014 09:38:49 +0100

-1

On Jun 26, 2014, at 10:59 PM, Michael StJohns <[email-masked]> wrote:

> There's been a small but vocal minority

The fairly strong support for other curves from the CFRG to refutes this statement.

--Paul Hoffman

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Jun 2014 10:58:48 +0200

Hi Joachim,

> very interested in info on the code size and data memory during operation.

No, I haven't created a write-up yet. I believe I should make take a
look at other curves first to have a reasonable comparison.

I will try to put something together for the upcoming IETF meeting
(since it might be relevant to the LWIG working group).

(Code size and RAM size is a bit tricky since there is some other stuff
that need to be compiled into the code to make it useful.)

> So how did you do the random generation? Fixed values or some other
This is probably more an issue of embedded systems (rather than the TLS
working group in general) but I had to put fixed values in there since I
didn't want to rely on the library that some other person wrote and a
hardware random number generator was only available with another board
but the core mbed libaries do not yet offer the API.

In a nutshell, I used fixed values.

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Jun 2014 12:34:42 +0100

Hiya,

> AD should sponsor a discussion in SAAG?

Yes, this is not TLS specific, though its probably not really
possible to have no discussion of it here since TLS is likely
the first large "customer" for 25519 in the IETF, if the WG
choose to go that route.

CFRG is definitely a better location for any detailed crypto
discussion, i.e. for all algorithm internals. As noted before
there was no indication from CFRG at the interim that 25519
is problematic. That's not quite as ringing an endorsement
as has been represented here, but I figure cryptographers are
going to be like lawyers for this  - they'll never all agree
an algorithm/curve is perfect;-) So its also possible CFRG
might come up with more curves that they also like and that's
fine. If someone wants more curves generated, CFRG is the
place to chat about that and not here.

But at that interim 25519 was definitely considered ok for
use in IETF protocols - there was no dissent when I (more
than once) directly asked that question and said that I
wanted to hear dissent should there be any. The proximate
cause for my question was allocating a codepoint for ed25519
for ssh, which has happened and the associated draft has
completed IETF LC, also without any criticism of the use
of 25519. I'm waiting for an updated I-D on that before
putting it on an IESG telechat for approval, but my reading
of the IETC LC was that there were no cryptographic issues
raised at all. That IETF LC is also evidence that the IETF
consider 25519 is ok. That said, when/if TLS decide to use
it, I expect there'll be more interest in the IETF LC for
that, so we'll see what happens then.

For now anyway, my interpretation is that we don't have any
cryptographic (nor declared IPR) reason to not use 25519 if a
WG choose to want it. However, there is some more work to be
done to document that so it can be used by WGs. I think that's
being done by CFRG though, but if not, or if there are more
generic bits that need discussion then saag seems like a fine
list for that. If you think such a discussion on saag is needed
then please ping me offlist to explain exactly what we need
to discuss there (since I'm not clear about that). In the
meanwhile most of this thread does seem to me to better belong
on the CFRG list and is basically a distraction for TLS.

Also, I have to say the language in Mike's original mail was,
at best, unfortunate, e.g. "small but vocal minority agitating"
is not likely to kick off a calm reasoned debate, and is
definitely not going to help the TLS WG keep focused on its
work so I really hope folks don't respond in kind, and if the
chairs want to loudly stomp on threads with such language
(regardless of source and mostly regardless of topic) they
have my full backing.

Cheers,
S.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 27 Jun 2014 11:52:40 +0000

All good points!

I'd like to underscore that verifiably-random generated curves are likely to provide worse performance than, e.g., 25519 - but have a better chance of not bringing any cryptographic surprises later on. And in the (unlikely) case one of them does - the replacement path would be far simpler.

MIT LL Root CA: 

----- Original Message -----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, June 27, 2014 07:34 AM
To: Eric Rescorla <[email-masked]>; Michael StJohns <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, 

Hiya,

Cheers,
S.

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 28 Jun 2014 00:03:52 -0700

Here is an idealistic, but not unfeasible proposal that could lead to 
easier/broader adoption.

One way to attempt to unify the diverse world of ECC curves is to focus 
on the underlying field, as opposed the curve itself. Consider Fp 
operations with p=2^255-19 or p=2^256-189. In other words, for 
n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p 
"MUST". People who demand random primes will have to play along and 
accept less "randomness" in their curves.

This makes it more likely that the standard bodies, including national 
standards, agree to commit to a unified Fp, even when they are unable to 
embrace a single curve. This is a more realistic goal than to expect 
that one curve will satisfy everybody.

The performance in the Fp dominates the higher-level operation in ECC 
field. In software, Fp operations will be special-cased for p and 
various CPU architectures. It seems to me that such a fixed Fp will work 
as an incentive to add hardware support (for Fp). This allows the ECC 
code to have an interoperable, potentially hardware-assited layer, that 
is shared between all the curves (for the same n).

While we are on this, why was the Curve25519 not made to be Curve256189? 
(I don't think that 19 v.s. 189 would matter on x86) I suppose that the 
rest of the paper carries over unchanged (other than that the choice of 
the floating point registers is dated by now for modern x86 CPUs.)

Thank you.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 28 Jun 2014 15:59:20 -0400

Hi -

I waited about 48 hours to get most of the comments out there. With 
respect to Stephen's note, I mostly agree with his conclusions with 
respect to the current consensus within the IETF.  But I did want to 
address one particular comment he made as well as respond to some other 
comments.

EKR is correct that this is a larger question than TLS, unfortunately 
we're first up.

So first on "small but vocal minority agitating":

> (regardless of source and mostly regardless of topic) they

I'm not exactly sure what Stephen is objecting to in the above. Here's 
what I saw from in-person and email discussions:

A small group that was very vocal about throwing out anything to do with 
NIST/US Government crypto advocating for the use of Curve25519 as a 
replacement for the NIST curves and crypto and also advocating that it 
be the one true curve for the IETF.

A larger group that was more focused on performance and security and 
talking about the advantages of Curve25519 and then incidentally 
mentioning their discomfort with the possibility of tampering on the 
NIST curves.  (Hi Alyssa....)

A slightly larger group that was "looks OK to me as an additional 
system" (maybe the majority of the CFRG based on transcripts?)

An even larger group that was "crypto?  Meh! Tell me what to use".

What I didn't see was hue and cry from ACI Worldwide, American Express 
Company, American Financial Services Association, Bank of America, 
Capital One, Certicom Corporation, Citigroup, Inc., Deluxe Corporation, 
Diebold, Inc.,Discover Financial Services, eFunds Corporation, Federal 
Reserve Bank, First Data Corporation, Fiserv, Hewlett Packard, Hypercom, 
IBM Corporation, Ingenico, J.P. Morgan Chase & Co, KPMG LLP, MagTek, 
Inc., MasterCard International, National Association of Convenience 
Stores, National Security Agency, NCR Corporation, Savvis, SWIFT, The 
Clearing House, Unisys Corporation, University Bank, VeriFone, Inc., 
VECTORsgi, VISA, Wachovia Bank,  and Wells Fargo Bank to throw out the 
existing EC cryptography.

The above list of companies are those listed in the preface of the X9.62 
ECDSA crypto standard as participants/approvers for X9 and ultimately a 
group like that or larger are ones that will decide whether or not 
specific crypto will be acceptable for the commercial community. [X9.62 
ECDH had a similar group, but would have required more work on my part 
to edit it down to the company list]

In the scheme of things, the IETF participants are - sorry - a very very 
small minority of the people who have to be happy with Curve25519.  
Unlike all the other EC stuff we do (to specifically include the 
brainpool curves), Curve25519 is NOT within an accepted cryptography 
standard.   For the IETF to decide it wants to go into such business 
seems to be way outside our competences.

My original suggestion was meant to address the "NIST curves might be 
booby trapped" concerns of the first two groups I note above in a way 
that would be acceptable to that larger commercial community and for no 
other reason.

Going back to Stephen's comment - Stephen, would you care to craft a 
better description of the first group for me?  I didn't mean to offend, 
but I seriously don't think my "language" should be "loudly stomped" and 
I'm unclear why you do.

 >>>>  "IPR Issues":

The specific set of IPR issues that concern me are the license and 
copyright with respect to DJB's basic work.    Unless there is a 
"perpetual, paid up, world-wide, irrevocable" license for anything that 
he's done (or could do in this space) there are possible future issues.  
Something as simple as invoking the already existing copyright on the 
curve data could be problematic.

Note that I'm not saying this will happen, or that its even 
contemplated,  but it's a potential problem that should be resolved 
formally and legally.

(It's possible there is such a document, but I went looking and didn't 
find it.  Some of this is tagged "public domain" but that's probably 
insufficient for most lawyers).

If DJB et al is willing to transfer change control/copyright/patent 
rights/moral rights to the IETF (via appropriate documentation), and the 
IETF is willing to publish an actual standard then this objection goes away.

 >>>>> "CFRG has selected Curve25519 as the preferred curve for the IETF"

This statement was made in varying forms from "curve25519 is secure 
enough to be used" to "curve25519 is *the* curve for the IETF" in the 
discussion on this thread.  From reading the jabber log reference that 
was provided, I'd say that the former statement is more correct than the 
latter, but that's based on very little documentary evidence one way or 
the other.

In any event, there are probably a few procedural issues that need to be 
resolved before Curve25519 becomes "the" preferred curve and system for 
the IETF.  First is that the CFRG is a IRTF working group and not an 
IETF working group.  I believe that the CFRG can make recommendations, 
but the adoption of those recommendations as a BCP is an IETF issue.   
In the transcript I read, Yoav noted that a draft and RFC needed to be 
done.  So my take on the current state is that the CFRG has decided by 
voice vote/hum to make some sort of recommendation, but such 
recommendation has not yet been formalized.   Once that's done, then the 
IETF in the person of the SAAG, Security Area AD's and the IESG would 
need to take the recommendation and turn it into a BCP along with all 
the documentation necessary to make Curve25519 into a useable standard 
(e.g.  draft-josefsson-*, with TLS specifics removed so the crypto can 
be used in a general fashion).

*sigh* If the IETF is really going to get into the business of 
standardizing crypto, we need to get the process for doing so right the 
first time rather than just plugging it in to TLS and hoping we don't 
have to redo it over and over again.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Jun 2014 13:12:59 -0700

On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns <[email-masked]>
wrote:
[snip]

> resolved before Curve25519 becomes "the" preferred curve and system for the
> IETF.

To the best of my knowledge this question is not currently on the
table. Rather, the request to CFRG was to propose an additional
set of curves, not to propose a set of curves to be used in preference
to the existing standardized set. I suppose we could ask that question
as well, but I do not believe that is the current question at hand.

-Ekr

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 28 Jun 2014 13:31:47 -0700

On 06/28/2014 12:59 PM, Michael StJohns wrote:
> "perpetual, paid up, world-wide, irrevocable" license for anything 
> that he's done (or could do in this space) there are possible future 
> issues.  Something as simple as invoking the already existing 
> copyright on the curve data could be problematic.
>
> rights/moral rights to the IETF (via appropriate documentation), and 
> the IETF is willing to publish an actual standard then this objection 
> goes away. 

BTW, focusing on F(p) (which is not really an ECC) also helps with the 
above concerns. p = 2^n-C is free due to the following expired patent : 
https://www.google.com/patents/US5159632 .

IMO it would appear "safer" for hardware vendors to only 
implement/provide optimization primitives for F(p), for a couple of 
specific p's.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 28 Jun 2014 16:32:32 -0400

On 6/28/2014 4:12 PM, Eric Rescorla wrote:
>
>
>
> On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
> [snip]
>
>     In any event, there are probably a few procedural issues that need
>     to be resolved before Curve25519 becomes "the" preferred curve and
>     system for the IETF.
>
>

I don't know the reality of what the CFRG is doing/has done absent an 
actual document.   But that was the statement by Alyssa in her email on 
this thread and she referenced Rich Salz's email as saying the same 
thing or similar.

I think what you wanted is "Acceptable for use" (MAY):  I think what 
Rich said was "Recommended for use" (SHOULD) and I think what Alyssa 
said was "Preferred for use" (MUST UNLESS).  So what you asked for may 
not be what you got.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sat, 28 Jun 2014 16:39:32 -0400

On 6/28/2014 4:31 PM, Andrey Jivsov wrote:
>> (It's possible there is such a document, but I went looking and 
>> didn't find it.  Some of this is tagged "public domain" but that's 
>> probably insufficient for most lawyers).
>>
> above concerns. p = 2^n-C is free due to the following expired patent 
> : https://www.google.com/patents/US5159632 .
>

If I generated parameters for F(p) and published them under normal 
copyright, AFAIK you couldn't use them absent a copyright license 
regardless of patent rights.   For the existing curves, those grants of 
license exist in some form or another.   To avoid IPR issues, you need a 
set of both technology (patent) rights and parameter (copyright) rights.

As I said, I just want the documentation to avoid future issues.

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 28 Jun 2014 13:52:26 -0700

On 06/28/2014 01:39 PM, Michael StJohns wrote:
>>> the IETF is willing to publish an actual standard then this 
>>> objection goes away. 
>>
>> BTW, focusing on F(p) (which is not really an ECC) also helps with 
>> the above concerns. p = 2^n-C is free due to the following expired 
>> patent : https://www.google.com/patents/US5159632 .
>>
> regardless of patent rights.   For the existing curves, those grants 
> of license exist in some form or another.   To avoid IPR issues, you 
> need a set of both technology (patent) rights and parameter 
> (copyright) rights.
>

Staying within F(p), we know that 2^n - C is now free as an idea (ref. 
above). (There is a speculation is that P-521 was not made a part of 
Suite B due to that now expired patent )

It makes sense to have C smallest. C=189 for n=256 . ( As I wrote 
earlier, I don't see why it should be 2^255-19, but that p is selected 
using the same criteria )

It should be possible to find prior work by people who experimented with 
such primes. ( Starting from 
http://www.iacr.org/archive/ches2010/62250075/62250075.pdf, regarding 
2^256-189, and walking back in time... )

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Jun 2014 14:44:48 -0700

On Sat, Jun 28, 2014 at 1:32 PM, Michael StJohns <[email-masked]>
wrote:

> this thread and she referenced Rich Salz's email as saying the same thing
> or similar.
>
> I think what you wanted is "Acceptable for use" (MAY):  I think what Rich
> said was "Recommended for use" (SHOULD) and I think what Alyssa said was
> "Preferred for use" (MUST UNLESS).  So what you asked for may not be what
> you got.
>

Well, as you say, so far we don't have anything, however, I was on the
call (and said that what TLS needed was more or less what I said in
the material quoted) above and I don't remember anyone disagreeing. I
didn't hear any real discussion of CFRG making a recommendation that would
supplant the existing curves that have been standardized and I certainly
don't think that there was any sort of consensus to do so. Again, this isn't
to say that the CFRG might not wish to recommend that, but I don't
believe that is the question that was asked.

Since we are discussing this in the context of TLS, historically the
TLS WG has not said that one ought to use a particular set of
cryptographic algorithms, either at MUST *or* SHOULD level. Rather, we
have decided:

1. What algorithms get code point assignments at either standards track
or non-standards track levels.

2. What algorithms we require you to implement to be conformant.

3. What algorithms we recommend one not use in the future even
though they have code point assignments (as in Andrei's RC4 draft).

Note that these don't really fall cleanly into the MAY/SHOULD/MUST
classification you suggest here, but as I say, that's our historical
practice
and so far I haven't heard much discussion of changing that practice
for TLS.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 28 Jun 2014 18:24:34 -0400

> If DJB et al is willing to transfer change control/copyright/patent rights/moral
> rights to the IETF (via appropriate documentation), and the IETF is willing to
> publish an actual standard then this objection goes away.

Okay, I think we can knock this one off the list.  Sean Turner is writing an RFC and Tanja (and me) will be helping. Dan gives his approval but didn't have time to help. 

I agree that the IETF is a small group, especially compared to ANSI X9.62 and such.  But that doesn't mean we can't, or shouldn't, get back into the crypto standardization.  We have way more involved from real cryptographers than before.

> *sigh* If the IETF is really going to get into the business of standardizing
> crypto, we need to get the process for doing so right the first time rather
> than just plugging it in to TLS and hoping we don't have to redo it over and
> over again.

Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Michael StJohns <[email-masked]>
Date: Sat, 28 Jun 2014 18:55:31 -0400

> Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.

Um... huh?  Can you provide specifics about which cryptographic 
algorithms  we standardized?  This is news to me.

And I'm not talking about "here's how you use ECDSA for TLS or ECDH for  
for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 
or X9.63.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Sat, 28 Jun 2014 16:04:54 -0700

>>> *sigh* If the IETF is really going to get into the business of
standardizing
>> Agree.  But again, it's "back into the business"  Because we did it
before with TLS1, IPsec, and ECC curves therein.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring
lessons from IPSEC.

> And I'm not talking about "here's how you use ECDSA for TLS or ECDH for
for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or
X9.63.

What's magical about ANSI? Furthermore,  we aren't developing an algorithm,
but documenting one that already exists, the way RFC 6090 claimed to.

There is nothing magical that makes using AES secure. You always have to
know what you are doing.

So I don't see picking curve25519 as inherently riskier then decisions we
make every day in this WG.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 28 Jun 2014 19:36:31 -0400

On 6/28/2014 7:04 PM, Watson Ladd wrote:
>
>
> On Jun 28, 2014 3:55 PM, "Michael StJohns" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >

I can't find an RC4 RFC, but Camellia and HMAC are both Informational 
rather than Standards track.  The IETF does not own change control on 
either of these.  And since the publication of the HMAC RFC (2104), NIST 
has published their version of HMAC and that one seems to be the one 
most referenced these days.

TESS, CASt-128, RC2, RC5, MD4, MD5, GOST, UMAC(??) and AES Key Wrap are 
also Informational RFCs.  I'm sure there are a number of others, but I 
couldn't find any that are currently IETF standards or on the standards 
track.

So, no, AFAIK we haven't been in the crypto standards business.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Jun 2014 16:51:01 -0700

On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns <[email-masked]>
wrote:

> rather than Standards track.
>

I'm not sure why this is a relevant distinction. These documents are
published by IETF and we make normative references to them in
Standards Track documents. See, for instance:

http://datatracker.ietf.org/doc/rfc2104/referencedby/

> The IETF does not own change control on either of these.
>

How does this matter? Unlike protocols, cryptographic algorithms aren't
really versioned. If we wanted to do a new version of HMAC, we would
presumably call it HMAC-2 or something. What's needed is a stable
reference.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Jun 2014 13:24:07 +0100

Mike,

On 28/06/14 20:59, Michael StJohns wrote:
> 
> I'm not exactly sure what Stephen is objecting to in the above.

Objecting is the wrong word, I commented that your language
was unfortunate, at best.

Reasons:

1) most of this thread is off topic for TLS and on topic for
CFRG as has been said, I'd expect someone familiar with the
topic to know that, and someone unfamiliar with the topic to
begin with a lot less aggression - you did neither

2) starting an off-topic thread by calling some IETF participants
"agitators" is definitely undesirably aggressive and IMO close to
being disruptive

You can reply with as many words as you like, but I think the
above will remain the case, so I hope that no more discussion
of this aspect is needed.

S.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 29 Jun 2014 15:28:45 -0400

> was unfortunate, at best.
And then followed up with a command to "stomp on threads with such 
language" - hard not to take that as an objection.

> begin with a lot less aggression - you did neither

I asked a simple question about alternatives to Curve25519 because there 
have been repeated (I've got 208 messages including this thread) 
messages ON THIS WORKING GROUP about the use of Curve25519. Why this 
question is any more off-topic than those is unclear.

  Why you believe my question was aggressive is unclear to me.  Why you 
believe that I'm unfamiliar with the topic is also unclear (I'm 
unfamiliar, due to lack of documentation as to the CFRG's exact and 
final recommendation with respect to Curve25519, I'm familiar with most 
of the arguments for the curve,  and familiar with the differences in 
supporting documentation and standards from existing curves and curve 
generation systems).

> "agitators" is definitely undesirably aggressive and IMO close to
You get to have your own opinions, but try and leave the facts intact.

What I said was "There's been a small but vocal minority agitating for 
the adoption of Curve25519".  This is not the same as calling them 
agitators and I'll thank you not to put words in my mouth.

It turns out that the intransitive verb "agitating" and the noun 
"agitator" have different nuanced meanings probably leading to your 
confusion.    The former tends to imply "arousing interest 
enthusiastically" and is a neutral term.  "Agitator" is a neutral to 
negative term depending on context.   A simple pass by Merrium-Webster gets:

> to try to get people to support or oppose something

and
>
> intransitive verb
> *:*  to attempt to arouse public feeling </agitated/ for better schools>

The related none for "agitate" is "agitation" not "agitator".

Agitator gets you:
> : a person who tries to get people angry or upset so that they will 
> support an effort to change a government, company, etc.
and
> /a/ *:* one who stirs up public feeling on controversial issues 
> <political /agitator//s/>

I tend to use English with fair precision.  I could have used 
"advocating for" but there was a lot more lobbying going on than that 
word implies.

In any event, you're taking or implying offense where none was meant.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 29 Jun 2014 16:25:36 -0400

In line below.

On 6/28/2014 7:51 PM, Eric Rescorla wrote:
>
>
>
> On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns 
>>     On Jun 28, 2014 3:55 PM, "Michael StJohns"
>>     >> Agree.  But again, it's "back into the business"  Because we
>>     did it before with TLS1, IPsec, and ECC curves therein.
>>     >
>>     >
>>     Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by
>>     ignoring lessons from IPSEC.
>>
>>
>
>     I can't find an RC4 RFC, but Camellia and HMAC are both
>     Informational rather than Standards track.
>
>

Hi Ekr - thanks for the question.

I think the question you're asking is "Why is the distinction between 
Internet Standard and informational RFC relevant to the use of 
Curve25519"?  That's the one I'll try and respond to.  Let me know if I 
got the question wrong.

Fact: Almost any one who wants to can publish an Informational RFC.
Fact: Informational RFCs are not Internet Standards.  They may be 
products of the IETF, but do not have to be.  They tend to be evaluated 
less strenuously than standards track RFCs.
Fact:  Every single cryptographic standard that the IETF has published 
as an RFC has been Informational.  None of them appear to be products of 
the IETF, but I could have missed one.
Fact:  The IETF has made no claim as to the strength of viability of 
crypto published as Informational RFCs.  E.g. we're just a user of 
cryptography, not an originator.

Observation:  The Curve25519 documents could have been published as 
Informational along the same basis as above.  Some of them may still be.
Observation:  The CFRG was asked to comment on Curve25519 - specifically 
to give a recommendation.
Observation:  At least one person on this email thread (and others 
elsewhere) have used the phrase "standardize Curve25519" - another used 
the word "preferred".

Tentative Theory: There is some desire to publish Curve25519 as an IETF 
Standards track document.  That is to give Curve25519 the mantle of 
"cryptography acceptable to the IETF".

Implication: The IETF will have to make some pronouncement or assurance 
as to the viability of Curve25519 to the wider world.  The IETF will 
have to maintain the Curve25519 standard.

That last implication is new for the IETF.  AFAIK, each and every 
cryptographic algorithm and mode documented by the IETF has an owner 
elsewhere and such claims of assurance are made there and maintenance 
and changes are done there.  We are not - at least at this time - a 
cryptographic standards body.  The change to become one should be 
intentional, rational and measured.

If I am in fact misreading the tea leaves, and a Curve25519 
cryptographic standard is to be published to the IETF as a DJB 
contribution and Informational and not a product of the IETF, then there 
are no implications and I'll leave this in peace.  But anecdotal 
evidence suggests that this is in doubt.

> presumably call it HMAC-2 or something. What's needed is a stable

Cryptographic algorithms are not versioned - mostly  (Although see 
co-factor changes to ECDH for example), but Cryptographic Standards 
certainly are.  RSA has gone through 5 or 6 versions, FIPS186 is now 
"-4", etc.

The algorithm part of a cryptographic standard is usually the least 
controversial and most stable part of the standard.  The hard stuff is 
the translation and representation language (for example the argument 
about Curve25519 with respect to big or little endian representation of 
the big integers).  There are also sometimes enhancements or new 
guidance's that can be added:  For example key pair generation for EC 
key pairs in F(p) - one version is to randomly generate a number in the 
interval [1..P), another one is to randomly generate a number in 
2^(n+64) and take that mod P.

In short, the algorithm is just a small part of the standard.

The cryptographic standard has to give us (the IETF) an interface we can 
use to the cryptographic algorithm.    If that standard is not an IETF 
standard, then we take what we're given and hope it meets our needs.

I find the fact that the current TLS curve25519 draft directly 
references DJB's paper problematic as the paper is missing even the 
basics necessary for what I would consider a cryptographic standard.   
DJB's paper is equivalent to no more than section 5 of the RSA 2.2 
http://www.emc.com/emc-plus/rsa-labs/pkcs/files/h11300-wp-pkcs-1v2-2-rsa-cryptography-standard.pdf 
standard.  What's needed is a document that fills in the rest and that 
the TLS (and IPSEC and SMime and... can reference) and it's unclear if 
we have the time, resources or desire to do this.

So yes, I think the question of IETF standard or Informational RFC is 
relevant.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Jun 2014 14:29:44 -0700

On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns <[email-masked]>
wrote:

> Curve25519"?  That's the one I'll try and respond to.  Let me know if I got
> the question wrong.
>

Sure, we can take it as that question.

> Fact: Informational RFCs are not Internet Standards.  They may be products
> of the IETF, but do not have to be.  They tend to be evaluated less
> strenuously than standards track RFCs.
> Fact:  Every single cryptographic standard that the IETF has published as
> an RFC has been Informational.  None of them appear to be products of the
> IETF, but I could have missed one.
> elsewhere) have used the phrase "standardize Curve25519" - another used the
> word "preferred".
>

This is where you lost me. Consider the following sequence of events:

1. Someone publishes a Curve25519 Informational RFC.
2. The CFRG sends the IETF a message saying "We think the Curve25519
is a good curve and the IETF should adopt it for use in IETF protocols"
(presumably in more formal language).
3. The TLS WG publishes a standards track document (assuming for
the moment that we believe that we are going to adopt any standards
track ECC cipher suites) which refers to the RFC published in #1.

To the best of my knowledge, there isn't any procedural problem with
doing this and it would be effectively what we did with, for instance, HMAC.
Do you believe that the IETF made some statements about the quality
of HMAC by publishing RFC 2104 and including HMAC in our protocols?

> elsewhere and such claims of assurance are made there and maintenance and
> changes are done there.
>

Can you tell me who that someone else is for HMAC or RC4?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Jun 2014 15:49:11 -0700

On Jun 29, 2014, at 12:28 PM, Michael StJohns <[email-masked]> wrote:

> What I said was "There's been a small but vocal minority agitating for the adoption of Curve25519".

How is the phrase "small but vocal minority agitating" a fact? If you are comparing the number of people seeking to have Curve25519 adopted versus the number seeking to not have it adopted, the first group is actually larger than the second. If you are saying that only people who are speaking on the list want to have Curve25519 be adopted and everyone else doesn't and thus the first group is a small minority, that's a gross assumption, not a fact. You have been active in the IETF long enough to know that many people stay silent not because they agree with the way things are, but because they are sick of the tone of the discussion.

The fact is that the CFRG believes that Curve25519 is good enough for adoption in IETF standards. It's fine if you disagree, but if you want to try to be fact-based, stick to facts that you can back up.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 29 Jun 2014 19:26:55 -0400

As I recall, RC4 also had some special issues that we turned a blind eye too, like being called “ARC4” for some time.

Perhaps someone directly involved can refresh my memory?

                /r$

---

From: Adam Caudill <[email-masked]>
Date: Sun, 29 Jun 2014 20:03:22 -0400

On Jun 29, 2014, at 6:49 PM, Paul Hoffman <[email-masked]> wrote:

> If you are saying that only people who are speaking on the list want to have Curve25519 be adopted and everyone else doesn't and thus the first group is a small minority, that's a gross assumption, not a fact. You have been active in the IETF long enough to know that many people stay silent not because they agree with the way things are, but because they are sick of the tone of the discussion.

There are certainly more people that want to see curve25519 adopted than those that are speaking up; myself included. I wouldn’t advocate requiring it, but there are cases where it would be useful. If it makes sense for an implementation, implement it, if not, don’t - but there’s no reason to prevent it from being used in the cases where it would add value. It performs well, it’s generally accepted to be secure - otherwise I’m sure the reaction from the CFRG would have been quite different.

This isn’t just about being non-NIST, it has real value from a performance and implementation perspective. Personally, I see no reason not to adopt it - though I wouldn’t go so far as to require it be implemented (though I think it should be in many cases), or state that it should be a preferred option.

-- 
Adam Caudill

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Jun 2014 17:05:49 -0700

> Perhaps someone directly involved can refresh my memory?

It was maybe a copyright issue about the source code, but definitely a trademark issue on the hame, so someone did a clean-source reimplementation and gave it a new name. ARC4 and RC4 were shown to interoperate fully.

--Paul Hoffman

---

From: "Peter Yee" <[email-masked]>
Date: Sun, 29 Jun 2014 17:14:02 -0700

I think the Wikipedia entry does a decent job of describing the situation:

http://en.wikipedia.org/wiki/Rc4#History

		-Peter Yee

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Sunday, June 29, 2014 5:06 PM
To: Salz, Rich
Cc: [email-masked]
Subject: [TLS] Off-topic: RC4

On Jun 29, 2014, at 4:26 PM, Salz, Rich <[email-masked]> wrote:

> As I recall, RC4 also had some special issues that we turned a blind eye
too, like being called "ARC4" for some time.
> Perhaps someone directly involved can refresh my memory?

It was maybe a copyright issue about the source code, but definitely a
trademark issue on the hame, so someone did a clean-source reimplementation
and gave it a new name. ARC4 and RC4 were shown to interoperate fully.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 29 Jun 2014 23:12:32 -0400

Ø  Implication: The IETF will have to make some pronouncement or assurance as to the viability of Curve25519 to the wider world.  The IETF will have to maintain the Curve25519 standard.

Mike, I know you’ve been involved in this stuff since before this stuff existed ☺, but I don’t understand this. Why do we have to make any assurance about anything other than ‘here is how to interoperate using 25519 in TLS’?

We’re not defining a standard, we’re not assuring the world about anything. We’ll have an RFC that says “here’s  how to do the math for 25519 and other things needed to interoperate” and we’ll have other RFC’s that say “here’s how to use that curve in this protocol.”

Why does it need to be more than that?  I know that I am not alone in this confusion.

                /r$

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Jun 2014 21:36:05 -0700

On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich <[email-masked]> wrote:
> Ø  Implication: The IETF will have to make some pronouncement or assurance
> as to the viability of Curve25519 to the wider world.  The IETF will have to
> maintain the Curve25519 standard.
>
> Mike, I know you’ve been involved in this stuff since before this stuff
> existed J, but I don’t understand this. Why do we have to make any assurance
> about anything other than ‘here is how to interoperate using 25519 in TLS’?

No, we are defining a standard, and we are making assurances. Let's
not kid ourselves: SPF might say experimental, but if you try to send
mail without it, you'll find out just how much of a standard it is. As
for making assurances, if someday a massive break is discovered in TLS
1.3 because we neglected cryptographic knowledge, we will rightfully
be blamed for it.

If 25519 was ROT13, a proposal to include it would rightfully be
laughed out of this WG. We've established the principle, now we're
just haggling over its limits.

Sincerely,
Watson Ladd

>
>
>
> We’re not defining a standard, we’re not assuring the world about anything.
> We’ll have an RFC that says “here’s  how to do the math for 25519 and other
> things needed to interoperate” and we’ll have other RFC’s that say “here’s
> how to use that curve in this protocol.”
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Jun 2014 12:02:09 -0400

On 6/29/2014 5:29 PM, Eric Rescorla wrote:
>
>
>
> On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns 
>>>         >> Agree.  But again, it's "back into the business"  Because
>>>         we did it before with TLS1, IPsec, and ECC curves therein.
>>>         >
>>>         >
>>>         > Um... huh?  Can you provide specifics about which
>>>         cryptographic algorithms  we standardized?  This is news to me.
>>>
>>>         Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0
>>>         by ignoring lessons from IPSEC.
>>>
>>>
>>
>     I think the question you're asking is "Why is the distinction
>     between Internet Standard and informational RFC relevant to the
>     use of Curve25519"?  That's the one I'll try and respond to.  Let
>     me know if I got the question wrong.
>
>
>     products of the IETF, but do not have to be.  They tend to be
>     evaluated less strenuously than standards track RFCs.
>     Fact:  Every single cryptographic standard that the IETF has
>     published as an RFC has been Informational.  None of them appear
>     to be products of the IETF, but I could have missed one.
>     Fact:  The IETF has made no claim as to the strength of viability
>     of crypto published as Informational RFCs. E.g. we're just a user
>     of cryptography, not an originator.
>
>     Observation:  The Curve25519 documents could have been published
>     as Informational along the same basis as above.  Some of them may
>     still be.
>     Observation:  The CFRG was asked to comment on Curve25519 -
>     specifically to give a recommendation.
>     elsewhere) have used the phrase "standardize Curve25519" - another
>     used the word "preferred".
>
>     Tentative Theory: There is some desire to publish Curve25519 as an
>     IETF Standards track document.  That is to give Curve25519 the
>     mantle of "cryptography acceptable to the IETF".
>
>
Sorry - delete from "That is to give..." - this was a bad edit.  I not 
actually sure what that last sentence was supposed to be.

I thought I covered this by:
> contribution and Informational and not a product of the IETF, then 
> there are no implications and I'll leave this in peace.  But anecdotal 

What DJB has written is the basic algorithm.  What needs to be written 
is the adaptation of that algorithm into a form that provides "enough 
detail to ensure interoperability between different implementations" 
[quote from RFC2040 on RC5].  My belief is that document should not be 
solely a TLS document.   If that document is written as an external DJB 
document and we reference it for TLS, that's fine - that's what we did 
with HMAC.   If instead we choose to write that document as a product 
and standard of the IETF, that's a whole different matter.  If we choose 
to "prefer" it then that's an even more interesting matter.

Up to this point the IETF hasn't "owned" a cryptographic standard. 
Creating an IETF standard based on Curve25519, if that happens, will be 
an endorsement, however indirect, of the underlying cryptographic 
constructs by the IETF.

> of HMAC by publishing RFC 2104 and including HMAC in our protocols?

No.  But HMAC was simply a re-publication by the authors to allow for 
better access by implementers, not an IETF standard.   Also, HMAC was 
more of a cryptographic mode rather than a cryptographic standard - the 
security of the mode was based on assumptions of the underlying hash(es) 
- less fundamental analysis was required so our use of it wasn't suspect.

>     cryptographic algorithm and mode documented by the IETF has an
>     owner elsewhere and such claims of assurance are made there and
>     maintenance and changes are done there.
>
>

At the time of publication, HMAC was the product of its authors and a 
republication of: 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430. These 
days its part and parcel of FIPS198.

With respect to RC4, I can't find that the IETF ever published an RFC 
documenting RC4 - but in any case it was a Ron Rivest trade secret that 
leaked and which Ron's been nice about letting us use - I'm not sure of 
its current legal status.   OTOH, Rivest did author RFC2040 on RC5 and 
RC5 modes.   It has this line in it: "This memo is a restatement of 
existing published material. "

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Jun 2014 12:31:35 -0400

Two opposing views on whether Curve25519 is destined for IETF 
standardization status.... and hence some of my confusion.

Rich - "here’s how to do the math for 25519 and other things needed to 
interoperate" is sort of the definition of what a cryptographic standard 
is - only question is whether its an externally owned/maintained 
document offered as an Informational RFC or an IETF standards track 
document.  If the latter, then the standard  (and indirectly the math) 
gets an IETF imprimatur and we haven't offered those - yet - for 
cryptographic standards.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Jun 2014 09:45:31 -0700

> Rich - "here’s how to do the math for 25519 and other things needed to
interoperate" is sort of the definition of what a cryptographic standard is
- only question is whether its an externally owned/maintained document
offered as an Informational RFC or an IETF standards track document.  If
the latter, then the standard  (and indirectly the math) gets an IETF
imprimatur and we haven't offered those - yet - for cryptographic standards.

Okay, we publish it as informational. But wait, that's being done by the
CFRG. So what is the problem here? We haven't done it before is not much of
a problem.

We do update informational RFCs: I think you are reading far more into the
distinction vis a vis IETF inolvement then actually exists.
>>> as to the viability of Curve25519 to the wider world.  The IETF will
have to
>>> Why does it need to be more than that?  I know that I am not alone in
this
>>> confusion.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Jun 2014 14:13:06 -0400

So on the one side, folks at the CFRG meeting and such said they want an IETF RFC document on how to use and represent 25519.  That the external documents aren't enough.

On the other side, you are saying "no half measure" and that if we specify how to implement and use 25519, then we are writing a crypto standard and we've never done that before.

Do I have that right?

If yes, then my reply is "so what."  Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

Whatever.  Angels on the head of a pin.
	/r$

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Jun 2014 16:59:04 -0400

Someplace in the middle of all this the question I asked seems to have 
gotten lost.  Basically, "would generating IETF curves obviate the need 
for Curve25519 or others?" which I would say got answered "no".  The 
rest of all this is a side show with how Curve25519 gets into the IETF 
toolkit. 'nuff said.

> On the other side, you are saying "no half measure" and that if we specify how to implement and use 25519, then we are writing a crypto standard and we've never done that before.

I would agree with "need a document to represent and use 25519", its who 
said that and how it was said that I'm unclear on.   That document will 
have the form of a crypto standard irrespective of who writes it.  If it 
gets published like each and every other RFC we've done on crypto - as 
Informational and externally originated, then it isn't anything new.   
If we run it through our standards process, then it is.

> If yes, then my reply is "so what."  Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

I actually used the word "assurance".  Standards bodies don't get stuck 
with liability per se.

The IETF has an open process, scope of expertise and a reasonable 
commercial and international reputation.  Putting the IETF stamp of 
approval (in the form of placing it on the standards track) on a 
specific cryptographic algorithm and its associated standards lends that 
reputation to the standard more or less with a hit to the reputation if 
there's a failure.  If we want to begin doing this for cryptography in 
general, then we need to understand the real-world implications, both of 
the endorsement and possible failures.

Mike