[blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

2023-08-28 Thread 'David Adrian' via blink-dev
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

Re: [blink-dev] Re: Intent to Experiment: TLS Encrypted Client Hello (ECH)

2023-08-30 Thread 'David Adrian' via blink-dev
> looks of it 115 is slated to go out in July?) > > Thanks, > -- > Achiel van der Mandele > Product Manager > > > On Fri, Jun 9, 2023 at 11:13 AM 'David Adrian' via blink-dev < > blink-dev@chromium.org> wrote: > >> We've been running ECH at

Re: [blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

2023-09-08 Thread &#x27;David Adrian&#x27; via blink-dev
at the start, and TCP is stream-based). On Fri, Sep 1, 2023 at 4:00 PM Mike Taylor wrote: > 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! > > t

[blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-11 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdavid...@chromium.org, dadr...@google.com ExplainerNone Specificationhttps://datatracker.ietf.org/doc/html/draft-ietf-tls-esni Summary The TLS Encrypted ClientHello (ECH) extension enables clients to encrypt ClientHello messages, which are normally sent in cleartext, under a serve

[blink-dev] Re: Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-11 Thread &#x27;David Adrian&#x27; via blink-dev
ECH has been at 10% stable since 2023-08-31, and at 1% stable from Chrome 115. General metric impact is negligible. The spurious regressions at 1% appear to have gone away at 10%. The ECH "origin trial" was managed by Finch, since the TLS stack completes before the web stack is available. ECH use i

[blink-dev] Re: Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-11 Thread &#x27;David Adrian&#x27; via blink-dev
Updated in Chrome Status . On Monday, September 11, 2023 at 10:53:13 AM UTC-6 djac...@mozilla.com wrote: > Exciting news! > > Can you update Firefox / Gecko's status to 'Shipped / Shipping' with a > link to our intent to ship >

[blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

2023-09-18 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdadr...@google.com ExplainerNone Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html Summary Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was al

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-18 Thread &#x27;David Adrian&#x27; via blink-dev
>> On Sat, Sep 16, 2023 at 5:35 PM David Benjamin >> wrote: >> >>> On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss >>> wrote: >>> >>>> >>>> >>>> On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor >>>> wrote: >>

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

2023-09-18 Thread &#x27;David Adrian&#x27; via blink-dev
e and Remove" > <https://www.chromium.org/blink/launching-features/#feature-deprecations> > rather than an "Intent to Ship". I'll let an API owner say if there's a > reason to re-send it; probably there isn't. > > On Mon, Sep 18, 2023 at 3:47 PM '

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

2023-09-19 Thread &#x27;David Adrian&#x27; via blink-dev
correlation with an unrelated crash >>>> in Blink >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, >>>> since the deprecation rollout was fairly large. It only showed at 10%, not >>>> 1%. >>>> >>> > How

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-20 Thread &#x27;David Adrian&#x27; via blink-dev
ain Chromium version, that is most often >> based on the explainer, not any specification. >> >> Just as an example of something an explainer might have mentioned is why >> this involves keys in DNS and if HTTPS depends on DNS, what about DNS over >> HTTPS? It often say

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

2023-09-25 Thread &#x27;David Adrian&#x27; via blink-dev
only thing of note was a correlation with an unrelated >>>>>> crash in Blink >>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, >>>>>> since the deprecation rollout was fairly large. It only showed at 10%, >

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-26 Thread &#x27;David Adrian&#x27; via blink-dev
amin is right that we are effectively jamming a >>> TLS change from the IETF through a process designed for the Web Platform >>> and W3C. We mostly do this so that launches show up in Chrome Status, and >>> organizations who are interested in following TLS changes can see the

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

2023-09-26 Thread &#x27;David Adrian&#x27; via blink-dev
Great follow up to https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ. Big fan! On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > phan...@microsoft.com, h...@chromium.org > > Specification > https://d

Re: [blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

2023-11-29 Thread &#x27;David Adrian&#x27; via blink-dev
Updating this thread to say that Kyber has been at 10% stable on all platforms since 2023-11-06. On Friday, September 8, 2023 at 3:32:09 PM UTC-6 David Benjamin wrote: > On Fri, Sep 8, 2023 at 4:16 PM 'David Adrian' via blink-dev < > blin...@chromium.org> wrote: > >

[blink-dev] Intent to Prototype: Deprecate TLS SHA-1 server signatures

2023-04-03 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdadr...@google.com ExplainerNone Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html Summary Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was al

Re: [blink-dev] Intent to Prototype: Deprecate TLS SHA-1 server signatures

2023-04-03 Thread &#x27;David Adrian&#x27; via blink-dev
me for it yet. chrome://flags#use-sha1-server-handshakes. We also have a corresponding Finch flag and enterprise policy, etc. in Canary. On Mon, Apr 3, 2023 at 1:55 PM Mike Taylor wrote: > Hi David, > On 4/3/23 12:58 PM, 'David Adrian' via blink-dev wrote: > > Contact e

[blink-dev] Ready for Trial: Deprecate TLS SHA-1 server signatures

2023-06-07 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdadr...@google.com ExplainerNone Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html Summary Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was al

[blink-dev] Request for Deprecation Trial: Deprecate TLS SHA-1 server signatures

2023-06-08 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdadr...@google.com david...@chromium.org ExplainerNone Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html Summary Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server cert

[blink-dev] Re: Request for Deprecation Trial: Deprecate TLS SHA-1 server signatures

2023-06-08 Thread &#x27;David Adrian&#x27; via blink-dev
Per request on the previous thread , converting the previous Ready for Trial to an Intent to Experiment / Request for Deprecation Trial. Due to the nature of the TLS stack, this experiment will be managed by Finch, rather than sit

[blink-dev] Re: Intent to Experiment: TLS Encrypted Client Hello (ECH)

2023-06-09 Thread &#x27;David Adrian&#x27; via blink-dev
We've been running ECH at 50% Beta for TCP since I last posted (Nov 7, 2022). We recently landed support for ECH+QUIC, which is also running on Beta. We never made it to 1% Stable, so I'd like to continue to experiment / actually start a stable experiment, probably from 115-119. The main server

Re: [blink-dev] Re: Request for Deprecation Trial: Deprecate TLS SHA-1 server signatures

2023-06-13 Thread &#x27;David Adrian&#x27; via blink-dev
arefully rolling this out to > measure breakage seems like the right path forward. Do you have a timeline > along which you'd like to run this experiment? M115-M118? > > -mike > > > On Thu, Jun 8, 2023 at 9:54 PM 'David Adrian' via blink-dev < > blink-dev@chr

Re: [blink-dev] Intent to Ship: First-party sets

2023-06-21 Thread &#x27;David Adrian&#x27; via blink-dev
Is this I2S still using the externally managed JSON blob to identify first party sets, and shipping via Component Updater, i.e. there is not yet a dynamic way to specify First-Party Sets? On Tue, Jun 20, 2023 at 9:35 AM 'Hugo Bärtges' via blink-dev < blink-dev@chromium.org> wrote: > Have we reach

[blink-dev] Intent to Prototype: X25519Kyber768 key encapsulation for TLS

2023-06-26 Thread &#x27;David Adrian&#x27; via blink-dev
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

[blink-dev] Re: Intent to Prototype: X25519Kyber768 key encapsulation for TLS

2023-06-26 Thread &#x27;David Adrian&#x27; via blink-dev
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. - E

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

2024-03-18 Thread &#x27;David Adrian&#x27; via blink-dev
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

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

2024-03-20 Thread &#x27;David Adrian&#x27; via blink-dev
t; 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

[blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-03 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emails...@chromium.org ExplainerNone Specificationhttps://wicg.github.io/private-network-access Summary We propose to block access to IP address 0.0.0.0 in advance of PNA completely rolling out. Chrome is deprecating direct access to private network endpoints from public websites as par

[blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-03 Thread &#x27;David Adrian&#x27; via blink-dev
Chrome Status doesn't generate emails for the deprecation trails, only developer trials, so I've repurposed that here. This is a Finch managed rollout, not a developer opt-in, due to the extremely low usage that seems to be almost entirely malware. On Mon, Jun 3, 2024 at 12:03 PM David Adrian wro

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-03 Thread &#x27;David Adrian&#x27; via blink-dev
, right? Correct. On Mon, Jun 3, 2024 at 1:25 PM Vladimir Levin wrote: > > > On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev < > blink-dev@chromium.org> wrote: > >> Chrome Status doesn't generate emails for the deprecation trails, only &g

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-04 Thread &#x27;David Adrian&#x27; via blink-dev
nterprise/Debuggability/Testing pills in Chromestatus? > > /Daniel > On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote: > > > Can you please elaborate on the analysis: how low is the usage and how > did you check that the use is malwa

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-04 Thread &#x27;David Adrian&#x27; via blink-dev
Bratell wrote: > >> Can you please start (or possibly N/A) the >> Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus? >> >> /Daniel >> On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote: >> >> > Can you

[blink-dev] Ready for Trial: TLS ClientHello extension permutation

2022-08-25 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdavid...@chromium.org, dadr...@google.com Specificationhttps://datatracker.ietf.org/doc/rfc8446 Design docs https://docs.google.com/document/d/1NIeWj_xFE3p7Q2IxVjnztO4_Aqih3VAskHlLYqDFjvk/edit?resourcekey=0-FCsdas1l23L830egKOun4A https://github.com/dadrian/clienthello-randomization

[blink-dev] Re: Intent to Experiment: TLS Encrypted Client Hello (ECH)

2022-11-07 Thread &#x27;David Adrian&#x27; via blink-dev
An update: - We are deploying to 50% Beta as I write - We have seen very little usage so far, however the usage we do see is basically entirely successful. The main issue at this point is Chrome does not yet support ECH with QUIC connections, and the main deployment we know of prefers QU

Re: [blink-dev] Re: Ready for Trial: TLS ClientHello extension permutation

2022-11-17 Thread &#x27;David Adrian&#x27; via blink-dev
Updating this to say: 1) I screwed up and this really should have been an Intent to Experiment. 2) We've been experimenting behind Finch / staged rollouts, and have seen no change in overall metrics, and no increase in SSL errors, from Canary/Dev, through Beta and 1% Stable. We also heard off-thr

[blink-dev] Intent to Ship: TLS ClientHello extension permutation

2022-11-17 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdavid...@chromium.org, dadr...@google.com Specificationhttps://datatracker.ietf.org/doc/rfc8446 Design docs https://docs.google.com/document/d/1NIeWj_xFE3p7Q2IxVjnztO4_Aqih3VAskHlLYqDFjvk/edit?resourcekey=0-FCsdas1l23L830egKOun4A https://github.com/dadrian/clienthello-randomization/

Re: [blink-dev] Intent to Ship: TLS ClientHello extension permutation

2022-11-18 Thread &#x27;David Adrian&#x27; via blink-dev
tions/issues/92 On Thu, Nov 17, 2022 at 7:15 PM Yoav Weiss wrote: > > > On Fri, Nov 18, 2022 at 1:28 AM Martin Thomson wrote: > >> >> >> On Fri, Nov 18, 2022 at 10:15 AM 'David Adrian' via blink-dev < >> blink-dev@chromium.org> wrote: >&

Re: [blink-dev] Intent to Ship: TLS ClientHello extension permutation

2022-11-28 Thread &#x27;David Adrian&#x27; via blink-dev
>> >>>>> I've filed requests for positions from Mozilla [1] and WebKit [2]. >>>>> >>>>> [1] https://github.com/mozilla/standards-positions/issues/709 >>>>> [2] https://github.com/WebKit/standards-positions/issues/92 >>>&g

Re: [blink-dev] Intent to Ship: TLS ClientHello extension permutation

2022-11-28 Thread &#x27;David Adrian&#x27; via blink-dev
I've copied the document into a public Chromium-doc <https://docs.google.com/document/d/13hbMJDFU8kZ_qtLukNYoWZOEnr0wRKeP6XBmY_TQ0B4/edit#> and updated the link on Chromestatus. On Mon, Nov 28, 2022 at 10:15 AM Yoav Weiss wrote: > > > On Mon, Nov 28, 2022 at 6:06 PM 'Da

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

2025-03-15 Thread &#x27;David Adrian&#x27; via blink-dev
vs. functionality tradeoff space. We did >>this for flash initially with things like blocking it for very small >>canvases. >>- Anything we can do to make WebGL work on a larger set of devices? >>- Probably lots of other ideas that aren't occurring to me

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

2025-04-24 Thread &#x27;David Adrian&#x27; via blink-dev
>>>>>> option would be to collect some UKM data for SwiftShader usage and >>>>>>>> review a >>>>>>>> random ~50 sites to observe the user experience in practice. That >>>>>>>> could >>>>>

Re: [blink-dev] Intent to Remove: SwiftShader Fallback

2025-02-19 Thread &#x27;David Adrian&#x27; via blink-dev
WebGL 1; only failing that do we > resort to using SwiftShader on the basis that showing the content with > potentially poor performance is better than not showing it at all. > > > On Thu, 13 Feb 2025 at 15:46, 'David Adrian' via blink-dev < > blin...@chromium.org>

[blink-dev] Intent to Prototype: Trust Anchor Identifiers (TAI)

2025-05-06 Thread &#x27;David Adrian&#x27; via blink-dev
Contact emailsdadr...@google.com Explainer https://github.com/tlswg/tls-trust-anchor-ids/blob/main/explainer.md Specificationhttps://github.com/tlswg/tls-trust-anchor-ids Summary Trust Anchor Identifiers (TAI) is a TLS protocol extension that enables a TLS server to efficiently advertise which

[blink-dev] Re: Intent to Prototype: Trust Anchor Identifiers (TAI)

2025-05-06 Thread &#x27;David Adrian&#x27; via blink-dev
Following up to say: - This is a TLS launch associated with an IETF draft, not a web platform launch associated with a W3C spec. As such, we are primarily doing the Blink process for visibility. - We will follow up with an Intent to Experiment (via Finch, not OT) - Since it's not

Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: SwiftShader Fallback

2025-07-09 Thread &#x27;David Adrian&#x27; via blink-dev
t;>>>> not >>>>>>>>> supported" error message. That's then potentially a huge number of >>>>>>>>> new >>>>>>>>> support requests to deal with. >>>>>>>>> >>>>>>>>> >>>>>