Subject: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

From: Timothy Jackson <[email-masked]>
Date: Wed, 23 Mar 2016 00:38:13 +0000

I’ve noted that many (most?) TLS implementations choose their ECDHE curves seemingly without regard to the cipher suite strength. Thus, they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key on the P256 curve. This seems odd to me, since the P256 curve obviously has a lower security strength than AES256. This seems important issue to resolve because most products (and even TLS libraries) do not allow the administrator to configure the available ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly undermining the security of your TLS connection.

Is this an intentional choice by this group for some reason that I haven’t realized yet?

How would this group feel about a proposal to address this by specifying in the 1.3 specification that implementations must ensure that the strength of the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? Perhaps an equivalency rule for the MAC might also be in order? Apologies if this is already resolved somewhere in the draft RFC. I looked but didn’t find it.

For what it’s worth, I’ve noticed OpenSSL and other implementations trying to address this by creating a “Suite B Mode”, but that seems to address a specific case but leave the generic case unresolved.

Cheers,

Tim

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Mar 2016 11:46:29 +1100

On 23 March 2016 at 11:38, Timothy Jackson <[email-masked]> wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?

There are good reasons to make certain parts of the suite stronger than others.

For example, record protection and ephemeral key exchange strength are
tied to the potential lifetime of the ciphertext.  If someone is
scooping up sessions, that could be a long time (lifetime might
actually need to be a lifetime).

On the other hand, authentication keys need only be strong enough to
resist a break until their expiration date.  To given an example, in
WebRTC, we used to use 1024-bit RSA keys; the lifetime of the keys was
a single session (and it was still too slow).

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Mar 2016 17:49:15 -0700

On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson <[email-masked]>
wrote:

> I’ve noted that many (most?) TLS implementations choose their ECDHE curves
> seemingly without regard to the cipher suite strength. Thus, they'll select
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
> generate an ECDHE key on the P256 curve. This seems odd to me, since the
> P256 curve obviously has a lower security strength than AES256. This seems
> important issue to resolve because most products (and even TLS libraries)
> do not allow the administrator to configure the available ECDHE curves,
> only the cipher suites. Thus, ECDHE may be invisibly undermining the
> security of your TLS connection.
>
> How would this group feel about a proposal to address this by specifying
> in the 1.3 specification that implementations must ensure that the strength
> of the certificate must be >= strength of ECDHE/DHE >= strength of the
> cipher? Perhaps an equivalency rule for the MAC might also be in order?
> Apologies if this is already resolved somewhere in the draft RFC. I looked
> but didn’t find it.
>

Off the top of my head, this rule seems like it would have several quite
negative
side effects:

- It would require you to use Curve448 or P521 with ChaCha/Poly1305
  (256-bit key) but allow you to use Curve25519 with AES-GCM 128,
  which cuts against one of the major reasons to use ChaCha/Poly1305,
  namely that it's faster on mobile platforms.

- It would essentially preclude using RSA certificates with ECC at all,
  because the RSA modulus you need to match 256-bit ECC is impractically
  large.

It's also worth noting that AES-GCM 256 and 128 use the same authentication
tag size.

-Ekr

> For what it’s worth, I’ve noticed OpenSSL and other implementations trying
> to address this by creating a “Suite B Mode”, but that seems to address a
> specific case but leave the generic case unresolved.
>
> Cheers,
>
> Tim
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Mar 2016 02:20:00 +0000

> How would this group feel about a proposal to address this by
> specifying in the 1.3 specification that implementations must ensure
> that the strength of the certificate must be >= strength of ECDHE/DHE >=
> strength of the cipher?

Strongly opposed, for the reasons Martin said.  Insisting that everything line up is kinda like crypto OCD.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 22 Mar 2016 23:26:22 -0400

> How would this group feel about a proposal to address this by specifying in the 1.3 specification that implementations must ensure that the strength of the certificate must be >= strength of ECDHE/…

I've had a changeset sitting around for a while for recommendations (not hard requirements) to match the strengths for key exchange and bulk cipher key size. (it was leftover from a batch of other work, long since merged) That said, I'm not actually sure what my opinion is on this anymore. It's been on my todo list to bring up a discussion.

https://github.com/tlswg/tls13-spec/pull/296

There's complications here that make picking a matching number less than straightforward:

1) A main reason to switch to 256-bit ciphers is for post-quantum crypto, but all (EC)DHE is completely broken in that scenario. Bigger numbers there won't help in any meaningful way.

2) Neither AES-256 nor ChaChaPoly match up things perfectly, already. For PRF, AES-256 uses SHA2-384, not SHA2-512; ChaChaPoly uses SHA2-256. AES-256 also has a 128-bit block size.

3) There's more to group security than bits. For a start: https://safecurves.cr.yp.to/

At this time, I'm leaning towards sticking in a recommendation to prioritize the following groups, in this descending order:

X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then lastly, ffdhe8192 and/or secp521r1 only as emergency backup (arguably, X448 belongs back here too)

I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use for TLS 1.3+ and only support it for transition in older TLS. (this came up on-list a long while ago, but needs further discussion) I'd state secp384r1 and ffdhe6144 as "NOT RECOMMENDED" to bother with, but still permitted (or, alternatively, just not explicitly recommended and not recommended against).

I'd make the recommendation that X25519 and secp256r1, in that order, be sent in first-flight key shares, unless prior expectations exist for the server that another group is desired or required. Implementations would of course be permitted to send a more conservative set, such as (instead or additionally) X448 and ffdhe8192 or secp521r1, but even though I think this might make sense for 256-bit bulk ciphers, I concede that it would likely be overkill that wouldn't really help. Those who want something stronger should probably be refocusing their effort on getting some kind of PQ key exchange standardized.

Am I somewhere in the ballpark of what the WG might deem appropriate here? There has been a "TODO" note sitting in the draft to address this for quite some time, and I'd like to get something in here at some point. Just to restate: my goal here is a set of recommendations to narrow down the zoo, not hard requirements (beyond requiring ~128+ bit strength security).

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Mar 2016 10:42:19 +0200

On Wed, Mar 23, 2016 at 12:38:13AM +0000, Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384),
> but then generate an ECDHE key on the P256 curve. This seems odd to
> me, since the P256 curve obviously has a lower security strength than
> AES256. This seems important issue to resolve because most product
> (and even TLS libraries) do not allow the administrator to configure
> the available ECDHE curves, only the cipher suites. Thus, ECDHE may
> be invisibly undermining the security of your TLS connection.

The security levels are much less obvious than they at first seem.

128 bit symmetric encryption, 128 bit elliptic curve DH and 128 bit
MAC are not even _close_ to being the same security.

And if you want to configure things, configuring strong enough ECDHE
and strong enough ciphers should be enough... If 128-bit ECDHE is
enough, 256-bit symmetric encryption will certainly be enough (can't
say the same about 128-bit symmetric encryption).

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Wed, 23 Mar 2016 12:31:20 +0100

On Wednesday 23 March 2016 00:38:13 Timothy Jackson wrote:
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key
> on the P256 curve. This seems odd to me, since the P256 curve
> obviously has a lower security strength than AES256. This seems
> important issue to resolve because most products (and even TLS
> libraries) do not allow the administrator to configure the available
> ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly
> undermining the security of your TLS connection.

In my experience, many (12%) servers simply ignore the list of curves 
advertised by client and use the P-256 curve always.

Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 
is not advertised.

> Is this an intentional choice by this group for some reason that I

IMHO, it's just a result of limitation in the libraries - i.e. closer to 
"a bug" than "design choice"
 
> that the strength of the certificate must be >= strength of ECDHE/DHE
> >= strength of the cipher? Perhaps an equivalency rule for the MAC
> might also be in order? Apologies if this is already resolved
> somewhere in the draft RFC. I looked but didn’t find it.

Recommendation? maybe. Requirement? unneeded if not harmful, for the 
points already raised
 
> For what it’s worth, I’ve noticed OpenSSL and other implementations
> trying to address this by creating a “Suite B Mode”, but that seems
> to address a specific case but leave the generic case unresolved.

Only the new OpenSSL actually can use more than one curve on the server 
side...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Wed, 23 Mar 2016 12:45:07 +0100

On Tuesday 22 March 2016 23:26:22 Dave Garrett wrote:
> X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then
> lastly, ffdhe8192 and/or secp521r1 only as emergency backup
> (arguably, X448 belongs back here too)
> 
> I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use
> for TLS 1.3+ and only support it for transition in older TLS. (this
> came up on-list a long while ago, but needs further discussion)

DHE gets prohibitive (computationally) rather quickly, and given that 
1024 only /may/ have been broken, a "SHOULD NOT" for 2048 with "MUST use 
ephemeral key share" is IMHO more appropriate

> I'd
> state secp384r1 (...) as "NOT RECOMMENDED" to bother with,
> but still permitted 

I'd say it is a tad bit too strong of a wording for the strongest curve 
supported by SChannel...

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 23 Mar 2016 15:28:53 +0000

>>I’d state secp384r1 (...) as "NOT RECOMMENDED" to bother with,
>> but still permitted
>

+1 to Hubert.

---

From: Fedor Brunner <[email-masked]>
Date: Thu, 24 Mar 2016 11:13:01 +0100

> For what it’s worth, I’ve noticed OpenSSL and other implementations trying to address this by creating a “Suite B Mode”, but that seems to address a specific case but leave the generic case unresol…
There are good reasons to combine AES256 with ECDHE on the P256 curve.

Please read
https://blog.cr.yp.to/20151120-batchattacks.html

"Bottom line: 128-bit AES keys are not comparable in security to 255-bit
elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe?
Unclear."

There is also the paper "Understanding brute force" from Daniel J.
Bernstein.
https://cr.yp.to/papers.html#bruteforce

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Mar 2016 12:22:56 +0000

Hubert Kario <[email-masked]> writes:

>Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 is
>not advertised.

When I checked, which is a year or two back now, I found similar problems (I
didn't get hard figures but I had the feeling it was a lot higher than 12%,
but then I wasn't conducting a rigorous survey).  Conversely, I found that if
you just ploughed ahead with P-256, things usually worked.  This is what
motivated the use of P-256 in -LTS, it's the de facto standard curve.

Peter.