Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 13 users
Status: WontFix
Owner:
Closed: Dec 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Launch-OWP, Feature
Launch-Accessibility: ----
Launch-Legal: ----
Launch-M-Approved: ----
Launch-M-Target: ----
Launch-Privacy: ----
Launch-Security: ----
Launch-Status: ----
Launch-Test: ----
Launch-UI: ----



Sign in to add a comment
CECPQ1 for TLS
Project Member Reported by agl@chromium.org, Jul 7 2016 Back to list
(See http://www.chromium.org/blink#launch-process for an overview)

Change description:
CECPQ1 is a post-quantum cipher suite: one that is designed to provide confidentiality even against an attacker who possesses a large quantum computer. It is a key-agreement algorithm plugged into TLS that combines X25519 and NewHope, a ring-learning-with-errors primitive. Even if NewHope turns out to be breakable, the X25519 key-agreement will ensure that it provides at least the security of our existing connections.

This is only an experiment and will only be used on a small fraction of HTTPS connections between Chrome and Google. (Most connections between Chrome and Google will use QUIC, and we haven't integrated CECPQ1 into QUIC.)

The aim is to a) provide the research community a target because it would be very useful to know whether the ring structure in R-LWE is a mistake sooner rather than later and b) to test the real-world impact on latency and compatibility with the larger handshake messages that any post-quantum scheme seems likely to need.

For more background, see https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html


Changes to API surface:
Servers may negotiate CECPQ1-based cipher suites for TLS instead of ECDHE-based ones.


Timeline:
Remove within two years.


Support in other browsers:
None, and none expected.
 
Comment 1 by agl@chromium.org, Jul 13 2016
Labels: Type-Launch-OWP
Project Member Comment 2 by bugdroid1@chromium.org, Aug 12 2016
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

Project Member Comment 3 by bugdroid1@chromium.org, Aug 15 2016
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?
Comment 5 by agl@chromium.org, Dec 12 2016
Status: WontFix
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.
Sign in to add a comment