LGTM1
On Wed, Mar 20, 2024 at 8:35 PM David Adrian <dadr...@google.com> wrote:
> What's our plan to mitigate that risk? Slow rollout? Enterprise
policy? Both? Something else entirely?
We also worked with a variety of vendors to fix incompatibilities
that were brought to our attention, including Vercel, ZScaler,
and PayPal CN (who have all since patched prior to any level of
stable deployment).
> I'll LGTM once the review gates are flipped
Ack.
On Wednesday, March 20, 2024 at 1:58:33 AM UTC-4
yoav...@chromium.org wrote:
On Tue, Mar 19, 2024 at 10:23 PM David Benjamin
<davi...@chromium.org> wrote:
> I'm guessing we're talking about MITM middleboxes, is
that correct?
> What's our plan to mitigate that risk? Slow rollout?
Enterprise policy? Both? Something else entirely?
Whether the middlebox MITMs the TLS connection is not
terribly important. As long as they attempt to parse the
ClientHello, they will need to handle the larger
ClientHellos. They already do in that there's nothing
stopping session tickets, etc., making the ClientHello
large already, but Kyber makes it more likely.
We have already done a slow rollout. This has been
running on 10% stable for several months now, and so far
things seem to be fine. Some initial compat problems, but
largely fixed now. We're far, far, /far/ past the point
that there's nothing more we can smoke out without
proceeding to 100%.
And, yeah, the plan to mitigate the remaining risk is an
enterprise policy, PostQuantumKeyAgreementEnabled, that
admins can set while their middlebox vendors become
post-quantum-ready. The admin policy has been in place
for quite some time now, and has been communicated in
enterprise release notes. Also the presence of any such
incompatibility on an enterprise network blocks
/any/ deployment of post-quantum algorithms, so
ultimately the middleboxes will just need to get fixed.
The various ecosystem pressures towards getting to
post-quantum are particularly strong in enterprise
anyway, so hopefully admins will be more likely to
understand why it's important for them to fix those.
https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled
Makes sense, thanks!!
I'll LGTM once the review gates are flipped.
On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify)
<yoav...@chromium.org> wrote:
On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via
blink-dev <blin...@chromium.org> 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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
Search tags
tls <https://chromestatus.com/features#tags:tls>,
kem <https://chromestatus.com/features#tags:kem>,
kyber
<https://chromestatus.com/features#tags:kyber>,
postquantum
<https://chromestatus.com/features#tags:postquantum>
TAG review
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Post-quantum secure ciphers are larger than
classical ciphers. This may cause compatibility
issues with middleboxes.
I'm guessing we're talking about MITM middleboxes, is
that correct?
What's our plan to mitigate that risk? Slow rollout?
Enterprise policy? Both? Something else entirely?
/Gecko/: Shipped/Shipping
(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?
Debuggability
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
N/A
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 124
Origin trial desktop first 118
Origin trial desktop last 123
DevTrial on desktop 115
Shipping on Android 128
OriginTrial Android last 128
OriginTrial Android first 118
DevTrial on Android 115
Shipping on WebView 128
OriginTrial webView last 128
OriginTrial webView first 118
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
Intent
to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%40mail.gmail.com
We plan to ship Kyber (ML-KEM) by default on
/desktop platforms only/ starting in M124. Kyber
is a quantum-resistant key exchange mechanism for
TLS that defends against
harvest-now-decrypt-later
<https://bughunters.google.com/blog/5108747984306176/google-s-threat-model-for-post-quantum-cryptography>
attacks. This risk is relevant even if quantum
computers do not yet exist.
Due to the structure of TLS 1.3, Kyber key shares
are sent on the first ClientHello message
regardless of server support. Servers that do not
yet support Kyber will ignore it, and select a
different algorithm. Servers that do support
Kyber, such as GFEs and Cloudflare, will select
Kyber and respond with their own Kyber key
encapsulation.
Unfortunately, Kyber key shares are around 35x
larger than an X25519 key exchange, which
increases the latency of the TLS handshake
connections by 4-6%. On Desktop platforms, this
effect is largely in the noise due to the higher
likelihood of a high-bandwidth low-latency
connection, and connection pooling reuse (one TLS
handshake, many HTTP requests). On Android, this
effect is far more noticeable and results in
measurable regressions in LCP.
Therefore, we intend to ship Kyber by default on
Desktop platforms while we come up with a broader
strategy for when and how to ship post-quantum
cryptography on Android.
N.B. This Chrome Status entry is old and predates
the new approval system from summer 2023.
This intent message was generated by Chrome
Platform Status <https://chromestatus.com/>.
--
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/CAGkh42K4xE5n_Fbt8heqhNMC7-xf3RhNVopguK3YeTVoYM-VzQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42K4xE5n_Fbt8heqhNMC7-xf3RhNVopguK3YeTVoYM-VzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/CAOmohS%2BQfNtLkMRmf1o9-1GtVrDh6R2b_ugJeVNvjAQULPsTRA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BQfNtLkMRmf1o9-1GtVrDh6R2b_ugJeVNvjAQULPsTRA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKkvJmq-wT%3Dm6q20igyOr8qqgcLuCCjPYto%3D-F0FATbHg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKkvJmq-wT%3Dm6q20igyOr8qqgcLuCCjPYto%3D-F0FATbHg%40mail.gmail.com?utm_medium=email&utm_source=footer>.