Intent to Ship: AES_256_GCM in TLS.

[David Benjamin]

Contact emails

davi...@chromium.org

Spec

https://tools.ietf.org/html/rfc5246

Summary

We will be offering AES_256_GCM in TLS connections.

Motivation

Historically, TLS had two AES ciphers based on CBC mode, AES_128_CBC and AES_256_CBC. But TLS’s CBC mode construction was flawed, making it fragile and very difficult to implement securely (for the current taxonomy, see BEAST, Lucky Thirteen, and POODLE). TLS 1.2 added new AES-based ciphers, AES_128_GCM and AES_256_GCM, whose constructions do not have this problem.

When we originally implemented TLS 1.2 in NSS, we only added AES_128_GCM and not AES_256_GCM. AES_256_GCM requires a SHA-384 PRF which NSS did not support. We also did not consider AES_256_GCM to be worth the performance cost.

Unfortunately, many popular server implementations order ciphers numerically first, placing AES_256_CBC above AES_128_GCM. Those servers will select the obsolete AES_256_CBC when connecting to Chromium-based browsers, rather than our preferred AES_128_GCM.

We do not agree with this ordering, but we propose to add AES_256_GCM so that these servers will select a modern cipher with Chromium-based browsers. This should also simplify TLS configurations for administrators concerned with maximizing key sizes. We expect this to increase our usage of AES-GCM over the legacy CBC-mode ciphers.

For servers that use the client-provided ordering, we will be inserting AES_256_GCM below AES_128_GCM for now. However, as always, servers are free to assert their own ordering should they wish to use AES_256_GCM over AES_128_GCM.

Interoperability and Compatibility Risk

Negligible. This is a mature specification and AES_256_GCM is advertised by the recent versions of Edge and Safari.

Ongoing technical constraints

Negligible. Now that we are using BoringSSL, we can freely use ciphers that need a SHA-384 PRF.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug
https://crbug.com/591516

Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5659196699705344

Requesting approval to ship?

Yes.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

LGTM2

[Rick Byers]

LGTM3

[Hanno Böck]

Hi,

I have no problems with implementing AES256-GCM.

One quetion: Do you intent to implement all AES256-GCM modes or just
the FS-enabled ones? (I think the latter would make sense, nobody wants
to deploy RSA-kex-based stuff any more.)

And this:

On Wed, 02 Mar 2016 22:47:49 +0000
David Benjamin <davi...@chromium.org> wrote:

> Unfortunately, many popular server implementations order ciphers
> numerically first, placing AES_256_CBC above AES_128_GCM. Those
> servers will select the obsolete AES_256_CBC when connecting to
> Chromium-based browsers, rather than our preferred AES_128_GCM.

I raised this issue on the openssl list about a year ago. Nothing
happened, I just checked the latest alpha. Independent of what chrome
does I think openssl should be lobbied to change that.

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

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[David Benjamin]

On Thu, Mar 3, 2016 at 7:24 AM Hanno Böck <ha...@hboeck.de> wrote:

Hi,

I have no problems with implementing AES256-GCM.

One quetion: Do you intent to implement all AES256-GCM modes or just
the FS-enabled ones? (I think the latter would make sense, nobody wants
to deploy RSA-kex-based stuff any more.)

I was planning to add ECDHE and plain RSA. Not DHE because it's already behind a fallback and I expect to finish removing it in a release or two.

I'd love to lose plain RSA, but I don't expect we will be able to for a long time. In the meantime, it's nice not to have this majorization problem in our cipher suite list against some servers. From probing a list of top sites, we do seem to gain a bit of GCM usage by adding the plain RSA one. If Chrome-side metrics from early channels don't agree, I can certainly revise this.

(It also wouldn't make it harder for servers to remove plain RSA, and servers are the ones that risk an oracle from exposing it. Not that's likely to be realistic anytime soon either... :-/ )

 

And this:

On Wed, 02 Mar 2016 22:47:49 +0000
David Benjamin <davi...@chromium.org> wrote:

> Unfortunately, many popular server implementations order ciphers
> numerically first, placing AES_256_CBC above AES_128_GCM. Those
> servers will select the obsolete AES_256_CBC when connecting to
> Chromium-based browsers, rather than our preferred AES_128_GCM.

I raised this issue on the openssl list about a year ago. Nothing
happened, I just checked the latest alpha. Independent of what chrome
does I think openssl should be lobbied to change that.

I'll be sending them a patch later today which puts  CHACHA20_POLY1305 above AES_256_CBC because that's silly. I hope that one won't be controversial as their both in the 256 bucket. AES_128_GCM > AES_256_CBC probably will be, and I don't really have the time or energy to sink into that argument. I'd much rather just add AES_256_GCM on our end and largely stop having to worry about it.

David