Intent to Experiment: 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. https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

Blink component

Internals>Network>SSL

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 (https://github.com/mozilla/standards-positions/issues/874) Firefox is also in the process of rolling this out.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/244)

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?

Goals for experimentation

This is a Finch experiment, not site opt-in.

We are aiming to shake out bugs and incompatibilities with buggy TLS stacks that do not correctly handle large TLS ClientHellos. Announcing a public timeline for experimenting on stable provides the necessary justification for teams at companies who have buggy TLS stacks to prioritize fixing the bugs.

Ongoing technical constraints

Debuggability

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

Yes

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

Shipping on desktop	119
OriginTrial desktop last	118
OriginTrial desktop first	117
DevTrial on desktop	115

Shipping on Android	119
OriginTrial Android last	118
OriginTrial Android first	117
DevTrial on Android	115

Shipping on WebView

119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi David,

LGTM to experiment from M117 - M118 inclusive. I think that's what you're asking for - please let me know if I'm reading this incorrectly. Good luck!

thanks,
Mike

On 8/28/23 9:18 AM, 'David Adrian' via blink-dev wrote:

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. https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

Blink component

Internals>Network>SSL

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.

Any pointers to learn more about this possible compat problem?

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%40mail.gmail.com.

[David Adrian]

> LGTM to experiment from M117 - M118 inclusive. I think that's what you're asking for - please let me know if I'm reading this incorrectly. Good luck!

Thank you!

> Any pointers to learn more about this possible compat problem?

The basic issue is that the Kyber key exchange pushes the ClientHello size to be larger than one packet. This makes it more likely that the call to read() on the TCP socket will not return the entire ClientHello in a single call. Not all implementations are prepared for this (despite the fact that the ClientHello TLS record includes the length at the start, and TCP is stream-based).

[David Benjamin]

On Fri, Sep 8, 2023 at 4:16 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

> LGTM to experiment from M117 - M118 inclusive. I think that's what you're asking for - please let me know if I'm reading this incorrectly. Good luck!

Thank you!

> Any pointers to learn more about this possible compat problem?

The basic issue is that the Kyber key exchange pushes the ClientHello size to be larger than one packet. This makes it more likely that the call to read() on the TCP socket will not return the entire ClientHello in a single call. Not all implementations are prepared for this (despite the fact that the ClientHello TLS record includes the length at the start, and TCP is stream-based).

It is also conceivable that we run into some system that just caps the ClientHello size too tightly. Though so far all the issues we've seen have been just folks not understanding how to use sockets. An actual size limit would be a very, very tight constraint.

The main difference is that packetization issues will be a little flaky. You may just get (un)lucky and the whole ClientHello is available in one read() anyway. Also they can be made to trigger on smaller ClientHellos too, if we artificially send the ClientHello in two halves with a delay between them. But this difference is mostly only relevant to help diagnose the issue. (I.e. do you need to fix your socket reading logic, or fix some unreasonable size limit in your code?) The actual impact to page loads is about the same.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BoZZVLYf3hVfxe9RezK%2B_i26tL6M2r6aFLqd-cvoQvRg%40mail.gmail.com.

[David Adrian]

Updating this thread to say that Kyber has been at 10% stable on all platforms since 2023-11-06.