Subject: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519

From: Peter Beverloo <[email-masked]>
Date: Fri, 3 Jul 2015 15:15:25 +0100

Section five of draft-thomson-webpush-encryption-00 currently mandates
usage of the P-256 curve.

https://tools.ietf.org/html/draft-thomson-webpush-encryption-00#section-5

I'd like us to change this to use Curve25519 instead. Curve25519 provides
better security and performance properties than P-256, is easier to
implement correctly and is preferable to use in modern protocols.

Looking at the holistic picture - we're asking developers to implement a
fair amount of cryptographic logic in their back-end systems. The absence
of native AEAD_AES_128_GCM support in popular interpreted languages such as
Python and PHP is at least equally burdensome to adopters than the curve we
decide use.

Thanks,
Peter

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Jul 2015 14:38:02 -0700

> implement correctly and is preferable to use in modern protocols.

I chose P-256 because it's available.  25519 isn't.  Not in any
meaningful way.  Where it is available is rather exceptional: Go has
an implementation, and you can pick up PolarSSL or GNUTLS.

I didn't check the tree, but my copy of OpenSSL didn't offer 25519.
BoringSSL might, but again, that's fairly exceptional.

> fair amount of cryptographic logic in their back-end systems. The absence of
> native AEAD_AES_128_GCM support in popular interpreted languages such as

That's a markedly different situation.  AES-GCM is widely supported.
In this case the languages/libraries that don't support it are the
exceptions.

I did the research for Python a while back. You can use a trunk
version of pycrypto (I wonder if that is as poorly maintained as it
appears?) or any of a number of small wrappers, which seems a little
risky, I'll admit.  It's a little sad that PHP is as bad as it is.

(I'm a little surprised that you aren't asking for ChaCha/Poly; the
comparison between that and AES-GCM is remarkably similar to the 25519
vs. P-256 story, especially for small messages.)

---

From: Peter Beverloo <[email-masked]>
Date: Thu, 9 Jul 2015 16:03:57 +0100

Forwarding since this message has not shown up in the archives.

Shida - are people not subscribed to the list not allowed to post either?

---------- Forwarded message ----------
From: Ryan Sleevi <[email-masked]>
Date: Sat, Jul 4, 2015 at 7:08 AM
Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or
Curve25519
To: Martin Thomson <[email-masked]>
Cc: Peter Beverloo <[email-masked]>, "[email-masked]" <
[email-masked]>

On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson <[email-masked]>
wrote:

> meaningful way.

Well, without defining a meaningful way, sure :) Are you talking about
libraries or implementations? There are a wide variety of implementations,
in a wide variety of languages, generally of higher quality than those of
P-256 or AES-GCM.

Basically, what's the objective criteria we want to use here? That makes it
easier than a popularity contest, and at least helps keeps the debate
reasoned and objective. For example, if we're going to say "It's available
in PHP", but that requires compiling a bleeding edge trunk, then is that
available or not? Because if that does count, then it means that if 'we'
(the webpush community) were to contribute a curve25519 implementation to
php, then the problem is solved, right? And if not, and we mean something
like 'available in the PHP deployed by 80% of the web', then that's also
helpful to be explicit about. (I say PHP here, but it just as well could be
Java or Android or Python)

> Where it is available is rather exceptional: Go has

> BoringSSL might, but again, that's fairly exceptional.

So I presume you've measured "meaningfully available" as being bundled in a
particular cryptographic library. But that seems to be a misdirection,
because in the holistic picture, AES-GCM is widely available in
cryptographic libraries, except not meaningfully available in most
languages.

Here, I'm using "meaningfully available" for both AES-GCM and P-256 to
mean: Secure implementations (e.g. constant time, no timing leaks,
correct), ideally with hardware optimizations. In that criteria, anyone
"just grabbing" an implementation of P-256 off the shelf is almost
certainly going to do it wrong. Even NSS's implementation, until the past
month, was questionable.

So that's the problem. We've got this shifting goalpost of trying to say
what it means for HKDF/AES-GCM/P-256. Simply having it in a language
binding doesn't make it easy for developers if they can't use it because
the underlying implementation isn't secure, and that's the state for most
languages. And if you're going to roll your own, because of the need to
actually _ensure_ well-defined security properties, then Curve25519 is far
better for that, as it lacks the many implementation sharp edges of 25519.

> risky, I'll admit.  It's a little sad that PHP is as bad as it is.

So if the argument is that "If it's available in trunk, then it's
meaningfully available for the developer population", does that mean that
if a patch existed for NSS, we'd call it meaningfully available? Or if
there was a native language implementation for some subset of core
languages, in a way that was secure (in the ways that most of the P-256
implementations I've looked at are not), we'd move on?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Jul 2015 10:46:13 -0700

I realized that I didn't reply here.

What I meant to say was - and it was a subjective assessment,
certainly - that availability is important for something like this.
And I was only able to find implementations of 25519 in libraries or
languages that were inconvenient for my purposes.  On the other hand,
I have many options for P-256 that I consider acceptable.

I'm sensitive to the fact that the distinction between available and
good is important, but with all respect to the tin-foil-hats in the
galleries, I consider availability to trump things like 100%
constant-time, or being close to ideal performance.  I realize that
you hold high standards in this area.  I prefer to be a little more
pragmatic.

On 3 July 2015 at 23:08, Ryan Sleevi <[email-masked]> wrote:
> Here, I'm using "meaningfully available" for both AES-GCM and P-256 to mean:
> Secure implementations (e.g. constant time, no timing leaks, correct),
> ideally with hardware optimizations. In that criteria, anyone "just
> grabbing" an implementation of P-256 off the shelf is almost certainly going
> to do it wrong. Even NSS's implementation, until the past month, was
> questionable.
>
> what it means for HKDF/AES-GCM/P-256. Simply having it in a language binding
> doesn't make it easy for developers if they can't use it because the
> underlying implementation isn't secure, and that's the state for most
> meaningfully available for the developer population", does that mean that if
> a patch existed for NSS, we'd call it meaningfully available? Or if there
> was a native language implementation for some subset of core languages, in a
> way that was secure (in the ways that most of the P-256 implementations I've
> looked at are not), we'd move on?
>

---

From: Peter Beverloo <[email-masked]>
Date: Thu, 9 Jul 2015 19:08:56 +0100

> you hold high standards in this area.  I prefer to be a little more

Pragmatically speaking - the intended audience for implementations are the
libraries made available to application server developers. This means that
the functionality has to be available in the most popular programming
languages in order for people to adopt the functionality.

We know that at least PHP and Python will have difficulties supporting the
entire stack - notably because AES-GCM is unavailable. That's two major
languages right there, and it means that it's unreasonable for us to expect
any kind of good near-term adoption. (Ignoring the large players for a
moment, who build their own solutions.)

I agree that unavailability for OpenSSL is not great - let me follow up
there. There seems to be a proposed patch for NSS.

On a tangent, agl wrote a Python extension. We could do something similar
for a PHP module. Neither will solve AES-GCM unavailability.
  https://github.com/agl/curve25519-donna

Thanks,
Peter

On 3 July 2015 at 23:08, Ryan Sleevi <[email-masked]> wrote:
> >
> >
> > On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson <[email-masked]
> >
> > wrote:
> >>
> mean:
> binding

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 3 Jul 2015 23:08:32 -0700