Intent to Prototype: X25519Kyber768 key encapsulation for TLS

[David Adrian]

Contact emails

dad...@google.com

Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Summary

Protect current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement based on an IETF standard. This specification and launch is outside the scope of W3C. This key agreement will be launched as a TLS cipher, and should be transparent to users.

Blink component

Internals>Network>SSL

Motivation

In order to protect today’s network traffic against future quantum cryptanalytic attacks, we need to begin migrating network security protocols, like TLS, to use quantum-resistant cryptography. TLS will need to update to quantum-resistant cryptography in three separate areas: - Establishing, or agreeing upon a symmetric session key - Authenticating the server’s identity (e.g. X.509 certificate validation) - Authenticating the connection was established by the holder of the server’s private key This feature makes incremental progress on “External Encryption in Transit” by migrating TLS key agreement to a Kyber768 key encapsulation mechanism (ISE on Kyber and PQC strategy). Migrating TLS key agreement to quantum-resistant cryptography provides two important properties: - Protecting future network traffic against real-time interception and decryption - Protecting past and current network traffic against the store-and-decrypt attacks While the capability to break currently-deployed cryptography with quantum cryptanalytic attacks has not yet been publicly demonstrated, it is widely accepted that the “store” component of store-and-decrypt attacks are already underway and must be defended against. Past cryptographic algorithm rollouts have demonstrated that these migrations can take a significant amount of time to deploy, so its important to start before quantum computers exist

Initial public proposal

None

Search tags

tls, kem, kyber, postquantum

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers. This may cause compatibility issues with middleboxes.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

enable-tls13-kyber

Finch feature name

PostQuantumKyber

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1442377

Launch bug

https://launch.corp.google.com/launch/4252981

Estimated milestones

DevTrial on desktop

115

DevTrial on Android

115

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[David Adrian]

This is a TLS-stack launch, not a Blink launch, so it will take the following (estimated) shape:

• Beta in 115
  
• Experiment deployment to 1% Stable in 116 once the enterprise policy is available. We will send an Intent to Experiment prior to this, based on the results from Beta.
• Eventually, 100% stable. We will send an Intent to Ship once everything stabilizes.

The cipher is already implemented in Chrome, behind the enable-tls13-kyber flag.