Intent to Deprecate and Remove: TLS Next Protocol Negotiation (NPN)

[David Benjamin]

Primary emails
eng: b...@chromium.org, davi...@chromium.org
PM: si...@chromium.org

Summary
NPN was the TLS extension used to negotiate SPDY (and, in transition, HTTP/2). During the standardization process, NPN was replaced with ALPN, published as RFC 7301 in July 2014. We intend to remove NPN at the same time as the SPDY removal.

Motivation
As with SPDY and HTTP/2, the experiment has run its course and emerged from the standardization process. We would like to remove the pre-standard version. This moves the web forward and allows us to remove some code from Chromium and, eventually, BoringSSL.

NPN was originally intended for removal in 2015, but this was delayed due to lack of implementation availability. One year ago, we announced on the Chromium blog that both NPN and SPDY were to be removed early 2016. It is now 2016 and ALPN is widely available in many TLS and HTTP implementations.

See also the recent announcement on the Chromium blog last week.

Compatibility Risk
Early adopters of NPN that have not upgraded to ALPN may take a performance hit, but they will retain all functionality. Specifically:

Any server using NPN to negotiate SPDY/3.1 or HTTP/2 will return to using HTTP/1.1. They will lose all the performance improvements in HTTP/2, but it will function as before.

Some server software uses NPN to negotiate HTTP/1.1, but HTTP/1.1 is used without NPN. Instead, the motivation was likely TLS False Start, an optimization to save a round-trip on full TLS handshakes. We originally deployed it broadly but, due to compatibility issues, we limited it to hosts using NPN (and later ALPN).

NPN+HTTP/1.1 servers will lose False Start, although it is expected that some have already lost it. For security reasons, we’ve since further limited False Start to a few TLS ciphers (ECDHE + AEAD). This too only loses an optimization and no functionality.

Alternative implementation suggestion for server administrator
Server administrators should upgrade their servers to support ALPN and HTTP/2. They may also choose to do nothing as sites will continue to function regardless.

Usage information from UMA
Net.SSLProtocolNegotiation shows NPN and ALPN usage for HTTPS connections which negotiated at least one of them. From the past seven days worth of metrics, corrected to measure out of HTTPS connections overall, we have:

0.4-0.5% of handshakes negotiate SPDY/3.1 with NPN. (This would be affected by the SPDY removal anyway.) 0.2% of handshakes negotiate HTTP/2 with NPN. None of these sites will stop working. They'll return to HTTP/1.1 as before SPDY. For comparison, 38% of handshakes negotiate HTTP/2 with ALPN.

For completeness, 8-9% of handshakes negotiate HTTP/1.1 with NPN compared to 12% which do so with ALPN. These servers will continue to function but will lose the False Start optimization if they had not lost it already due to the increased cipher requirements. Updating to ALPN will restore the optimization (if other settings are sufficient), and HTTP/2 will give further performance benefits.

Requesting approval to remove too?

Yes, at the same time as SPDY/3.1, in May.

David

[David Benjamin]

Sorry, forgot these:

OWP launch tracking bug

https://crbug.com/587472

Entry on the feature dashboard
https://www.chromestatus.com/feature/5767920709795840

[Jochen Eisinger]

lgtm1

[Philip Jägenstedt]

LGTM2

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.

[Chris Harrelson]

LGTM3