Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-21 Thread Daniel Bratell 

LGTM3

/Daniel

On 2024-03-20 23:54, Mike Taylor wrote:


LGTM2. Good luck!

On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Mar 20, 2024 at 8:35 PM David Adrian  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
 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)
 wrote:



On Mon, Mar 18, 2024 at 3:37 PM '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

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

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-20 Thread Mike Taylor 

LGTM2. Good luck!

On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Mar 20, 2024 at 8:35 PM David Adrian  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
 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)
 wrote:



On Mon, Mar 18, 2024 at 3:37 PM '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

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?

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-20 Thread Yoav Weiss (@Shopify) 
LGTM1

On Wed, Mar 20, 2024 at 8:35 PM David Adrian  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 
>> 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 emailsdad...@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 componentInternals>Network>SSL
> 
>
> Search tagstls , kem
> , kyber
> , postquantum
> 
>
> TAG review
>
> TAG review statusNot 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
>

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-20 Thread 'David Adrian' via blink-dev 
> 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  
> 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 emailsdad...@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 componentInternals>Network>SSL 
 

 Search tagstls , kem 
 , kyber 
 , postquantum 
 

 TAG review

 TAG review statusNot 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 
 
 ?N/A

 Flag name on chrome://flagsenable-tls13-kyber

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-19 Thread Yoav Weiss (@Shopify) 
On Tue, Mar 19, 2024 at 10:23 PM David Benjamin 
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) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsdadr...@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 componentInternals>Network>SSL
>>> 
>>>
>>> Search tagstls , kem
>>> , kyber
>>> , postquantum
>>> 
>>>
>>> TAG review
>>>
>>> TAG review statusNot 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
>>> 
>>> ?N/A
>>>
>>> Flag name on chrome://flagsenable-tls13-kyber
>>>
>>> Finch feature namePostQuantumKyber
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442377
>>>
>>> Launch bughttps://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

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-19 Thread David Benjamin 
> 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

On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsdadr...@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 componentInternals>Network>SSL
>> 
>>
>> Search tagstls , kem
>> , kyber
>> , postquantum
>> 
>>
>> TAG review
>>
>> TAG review statusNot 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
>> 
>> ?N/A
>>
>> Flag name on chrome://flagsenable-tls13-kyber
>>
>> Finch feature namePostQuantumKyber
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442377
>>
>> Launch bughttps://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 discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com
>>

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-19 Thread Mike Taylor 
Also, would you mind requesting reviews for the various shipping gates 
(privacy, security, enterprise, etc.) in your chromestatus entry?


On 3/19/24 12:34 PM, Yoav Weiss (@Shopify) wrote:



On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev 
 wrote:



Contact emails

dadr...@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

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

?

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 last128
OriginTrial Android first   118
DevTrial on Android 115

Shipping on WebView 128
OriginTrial webView last128
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


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

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

2024-03-19 Thread Yoav Weiss (@Shopify) 
On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsdadr...@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 componentInternals>Network>SSL
> 
>
> Search tagstls , kem
> , kyber
> , postquantum
> 
>
> TAG review
>
> TAG review statusNot 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
> 
> ?N/A
>
> Flag name on chrome://flagsenable-tls13-kyber
>
> Finch feature namePostQuantumKyber
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442377
>
> Launch bughttps://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 discussionsIntent 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
> 
> 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
> .
>
> --
> You