Subject: ECDHE security level

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 10:13:57 -0700

Brian Smith noted some minor issues with the use of security level to
specify minimum ECDHE curve size.  Primarily, security level is based
on an evaluation of the curve, which can change over time (usually it
decreases).  If we intend to specify a 128 bit security level, we
might technically exclude the NIST P256 curve if there is a
cryptanalytic advance.  Secondly, if the CFRG chooses to bless 25519,
then it would be foolish of us to exclude what is a perfectly good
curve; currently it is considered to have a security level of ~126
bits.

The intent of this requirement was to avoid intentionally weak curve
choices from being used, not to generate potential ambiguity.

So, I'm going to propose that we simply reduce the minimum to 112
bits.  At 112 the elliptic curve is still stronger than the finite
field Diffie-Hellman minimum of 2048 (TLS 1.3 doesn't even permit the
use of something that weak).  ECRYPT II estimates that 112 is good
until around 2030, and equivalent to 2432-bit finite field DH.

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 11:49:19 -0700

> until around 2030, and equivalent to 2432-bit finite field DH.

I suggest that you avoid the subjective "security level" concept
completely and just say that that an ECDSA and ECDHE keys must be at
least 256 bits, and that an DHE, RSA, and DSA keys be at least 2048
bits. I'm actually not sure you want to have that limit for DHE keys,
but it seems like a good idea to have such a requirement for RSA keys.
Specifying a minimum ECC key size in the draft actuallly have very
little practicle effect since almost nobody is using ECC key sizes
less than 256 bits, but specifying the minimum RSA modulus size would
be a practical benefit, because quite a few servers are still using
1024-bit keys.

As you noted, "security level" is assessed differently by different
organizations. Also, as you noted, 224-bit ECC keys are commonly
assessed at the 112 bit security level, but you're not really
intending for 224-bit ECC keys to be acceptable.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 11:55:31 -0700

> intending for 224-bit ECC keys to be acceptable.

If we intend to permit 25519, then we'll need to permit something
lower than 256.  I don't see any reason why permitting ECC keys of 224
bits is a problem, do you?

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Oct 2014 22:04:47 +0300

> be a practical benefit, because quite a few servers are still using

RSA key exchange is not PFS, so are you talking about RSA certificates?

Also, bit crazy idea would be to set the bar at 120 bits. All "128-bit
secure" ones easily reach that by any reasonable definition, whereas
the less secure ones ("112-bit") tends to be significantly below that.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 12:06:05 -0700

> bits is a problem, do you?

In current practice, it is not a problem, because (virtually) nobody
supports any 224-bit curves anyway.

I do think that things should be specified in such a way that
Curve25519 would be acceptable. (I overlooked that the Curve25519 key
is not considered to be 256 bits long.) My main point is to try to
avoid "security level" because that's not a well-defined and
well-agreed-upon concept. I don't see why saying "224 bit keys" is
better than saying "250 bit keys" or "225-bit keys" unless the
intention is specifically to allow 224-bit ECC keys.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 12:13:47 -0700

> RSA key exchange is not PFS, so are you talking about RSA certificates?

Yes.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 12:13:42 -0700

> intention is specifically to allow 224-bit ECC keys.

Would 224-bit ECC be unacceptable in your mind?  All the sources I
have found consider it to be stronger than 2048 finite field.  Isn't
that the only relevant concern?  If no one actually implements and
deploys it, that's no big deal.  Especially if everyone is using
255/256 bits.

(BTW, I'll take up your point on signatures separately, it's worth considering.)

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 12:58:21 -0700

> deploys it, that's no big deal.  Especially if everyone is using

With my suggestions in the pull request, I was not intending to have
the spec changed so that 224-bit ECC is considered acceptable. I
merely wanted the language fixed so that P-256 and Curve25519 and
others were not forbidden on an unintended technicality, and so that
no ambiguous terms like "security level" were used.

My own opinion is that we tolerate RSA-2048-PKCS#1 only because we
have no other choice, due to legacy concerns, IPR FUD, and RSA's poor
performance. For that, and other reasons, whether 224-bit ECC is "good
enough" should be determined independently of what we tolerate with
RSA. I think there are some technical and non-technical reasons why it
would be difficult to get P-224 to actually be deployed in a
widespread manner. I also think there are better alternatives to the
224-bit curves I know of. Consequently, I'm not sure it is worth
spending time debating the suitability of 224-bit ECC.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 13:12:03 -0700

On 10 October 2014 12:58, Brian Smith <[email-masked]> wrote:
> I

OK, help me out here.  What would you like to see exactly.  I
currently have this:

"Ephemeral key exchange MUST have a minimum size of 2048 bits for DHE
or 255 bits for ECDHE."

Is that right?

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 14:16:23 -0700

> "Ephemeral key exchange MUST have a minimum size of 2048 bits for DHE

I am fine with that. I suggest that some browsers try to implement
those conditions to see how it goes.

Cheers,
Brian