The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0d8c5878789398cd393b6184b54b6cbfcb5948b

commit e0d8c5878789398cd393b6184b54b6cbfcb5948b
Author: mab <mab@google.com>
Date: Fri Aug 12 02:06:40 2016

Metric & meta-metric for CECPQ1 handshake latency.

To fairly measure the latency impact of CECPQ1, we need to measure only
hosts that will negotiate it.  Define a small group of Google hosts that
we believe ought to be negotiating CECPQ1, and a new histogram that
measures latency when connecting to these hosts.

In addition, add a meta-metric that (in the experiment group only)
allows us to verify that CECPQ1 is being negotiated in cases where we
expect it to be.  This will serve as a check on the quality of the first
metric.

BUG= 626363 

Review-Url: https://codereview.chromium.org/2192053002
Cr-Commit-Position: refs/heads/master@{#411518}

[modify] https://crrev.com/e0d8c5878789398cd393b6184b54b6cbfcb5948b/net/socket/ssl_client_socket.cc
[modify] https://crrev.com/e0d8c5878789398cd393b6184b54b6cbfcb5948b/net/socket/ssl_client_socket.h
[modify] https://crrev.com/e0d8c5878789398cd393b6184b54b6cbfcb5948b/net/socket/ssl_client_socket_impl.cc
[modify] https://crrev.com/e0d8c5878789398cd393b6184b54b6cbfcb5948b/net/socket/ssl_client_socket_pool.cc
[modify] https://crrev.com/e0d8c5878789398cd393b6184b54b6cbfcb5948b/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/537c7b14339a51c7c07b496a0ed05ca3a010bbb2

commit 537c7b14339a51c7c07b496a0ed05ca3a010bbb2
Author: mab <mab@google.com>
Date: Mon Aug 15 23:47:21 2016

Don't record post-quantum stats if MITM.

If something other than Google is terminating the TLS connection, then
we shouldn't expect the post-quantum ciphersuites to be present.  So,
exclude such connections from the statistics.

(Suggestion from estark--thanks!)

BUG= 626363 

Review-Url: https://codereview.chromium.org/2251483002
Cr-Commit-Position: refs/heads/master@{#412100}

[modify] https://crrev.com/537c7b14339a51c7c07b496a0ed05ca3a010bbb2/net/socket/ssl_client_socket_pool.cc

Is this still enabled in Chrome 54+?

I've tried a few combinations of Chrome / Chromium 54 - 57 on both Linux and Windows, but connections to play.google.com don't seem to use the CECPQ1 cipher suite.

Also, testing the browser in the SSL Labs client tester doesn't show CECPQ1 as one of the cipher suites. https://www.ssllabs.com/ssltest/viewMyClient.html

Is there a flag that needs to be set to enable this?

This experiment has concluded and so we don't expect Chrome to be advertising CECPQ1 at this point. The summary is at https://www.imperialviolet.org/2016/11/28/cecpq1.html, and I've also copied and pasted it below for the record:

CECPQ1 results (28 Nov 2016)

In July my colleague, Matt Braithwaite, announced that Chrome and Google would be experimenting with a post-quantum key-agreement primitive in TLS. One should read the original announcement for details, but we had two goals for this experiment:

Firstly we wanted to direct cryptoanalytic attention at the family of Ring Learning-with-Errors (RLWE) problems. The algorithm that we used, NewHope, is part of this family and appeared to be the most promising when we selected one at the end of 2015.

It's very difficult to know whether we had any impact here, but it's good to see the recent publication and withdrawal of a paper describing a quantum attack on a fundamental lattice problem. Although the algorithm contained an error, it still shows that capable people are testing these new foundations.

Our second goal was to measure the feasibility of deploying post-quantum key-agreement in TLS by combining NewHope with an existing key-agreement (X25519). We called the combination CECPQ1.

TLS key agreements have never been so large and we expected a latency impact from the extra network traffic. Also, any incompatibilities with middleboxes can take years to sort out, so it's best to discover them as early as possible.

Here the results are more concrete: we did not find any unexpected impediment to deploying something like NewHope. There were no reported problems caused by enabling it.

Although the median connection latency only increased by a millisecond, the latency for the slowest 5% increased by 20ms and, for the slowest 1%, by 150ms. Since NewHope is computationally inexpensive, we're assuming that this is caused entirely by the increased message sizes. Since connection latencies compound on the web (because subresource discovery is delayed), the data requirement of NewHope is moderately expensive for people on slower connections.

None the less, if the need arose, it would be practical to quickly deploy NewHope in TLS 1.2. (TLS 1.3 makes things a little more complex and we did not test with CECPQ1 with it.)

At this point the experiment is concluded. We do not want to promote CECPQ1 as a de-facto standard and so a future Chrome update will disable CECPQ1 support. It's likely that TLS will want a post-quantum key-agreement in the future but a more multilateral approach is preferable for something intended to be more than an experiment.