Re: [TLS] Working Group Last Call for ECH

Addressed via: https://github.com/tlswg/draft-ietf-tls-esni/pull/613 spt > On Apr 2, 2024, at 10:46, Russ Housley wrote: > > Signed PGP part > Thanks. > > This URL gives access without a paywall: > https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf > > Russ > >> On Apr 2,

Re: [TLS] Working Group Last Call for ECH

Thanks. This URL gives access without a paywall: https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf Russ > On Apr 2, 2024, at 10:31 AM, Stephen Farrell > wrote: > > > Hiya, > > On 02/04/2024 15:17, Russ Housley wrote: >> Joe: >> The ECH Internet-Draft includes this

Re: [TLS] Working Group Last Call for ECH

Hiya, On 02/04/2024 15:17, Russ Housley wrote: Joe: The ECH Internet-Draft includes this reference: [ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022. I'm guessing that'd be:

Re: [TLS] Working Group Last Call for ECH

Joe: The ECH Internet-Draft includes this reference: [ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022. This reference does not provide enough information for anyone to locate the document. I think a reference

Re: [TLS] Working Group Last Call for ECH

This WGLC has concluded. There is consensus to move this document forward. I think there are one or two minor changes proposed that should be incorporated into the revision we forward to the IESG. Joe On Thu, Mar 28, 2024 at 6:23 AM Sean Turner wrote: > Just a reminder that this WGLC ends

Re: [TLS] Working Group Last Call for ECH

Just a reminder that this WGLC ends soon! spt > On Mar 11, 2024, at 18:00, Joseph Salowey wrote: > > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the IESG and > send any comments to the list by 31

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 20, 2024 at 10:39 PM Raghu Saxena wrote: > > On 3/15/24 00:02, Eric Rescorla wrote: > > > > > > So, if I understand correctly, for my domain "abc.com > > ", I could > > purposely choose to have my ECHConfig public_name be "google.com > >

Re: [TLS] Working Group Last Call for ECH

On 3/15/24 00:02, Eric Rescorla wrote: So, if I understand correctly, for my domain "abc.com ", I could purposely choose to have my ECHConfig public_name be "google.com ", and As I said earlier, using "google.com " would

Re: [TLS] Working Group Last Call for ECH

Is there value in citing the security analysis for ECH as an informative reference? Yes! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > Is there value in citing the security analysis for ECH as an informative > reference? > > [image: 3548606.cover.jpg] > > A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | >

Re: [TLS] Working Group Last Call for ECH

Is there value in citing the security analysis for ECH as an informative reference? https://dl.acm.org/doi/abs/10.1145/3548606.3559360 A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena wrote: > > On 3/14/24 00:45, Eric Rescorla wrote: > > There are two questions here: > > > > 1. What the specification says > > 2. What implementations choose to do within the envelope of that > > specification. > > > > The specification needs to

Re: [TLS] Working Group Last Call for ECH

+1 to shipping it. On 11/03/2024 22:00, Joseph Salowey wrote: This is the working group last call for TLS Encrypted Client Hello [1].  Please indicate if you think the draft is ready to progress to the IESG and send any comments to the list by 31 March 2024.  The comments sent by Watson Ladd

Re: [TLS] Working Group Last Call for ECH

On 3/14/24 11:38, Raghu Saxena wrote: I think this is a feasible workaround. Actually I think it is almost better, since I can "fool" naive censors etc. into thinking users of my website are visiting "google.com" or something, since as a server operator I control the public_name. Regards,

Re: [TLS] Working Group Last Call for ECH

On 3/14/24 00:45, Eric Rescorla wrote: There are two questions here: 1. What the specification says 2. What implementations choose to do within the envelope of that specification. The specification needs to prescribe a set of behaviors that promote interoperability, which means that

Re: [TLS] Working Group Last Call for ECH

Hi, Eric, > On Mar 14, 2024, at 00:45, Eric Rescorla wrote: > > There are two questions here: > > 1. What the specification says > 2. What implementations choose to do within the envelope of that > specification. > > The specification needs to prescribe a set of behaviors that promote >

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 9:20 AM Amir Omidi wrote: > > I don't think it's realistic for a generic client (e.g., a standard > browser) to omit or falsify this field. > > Why not? From my understanding the issue that happens in this situation is > that the website becomes less reliable for these

Re: [TLS] Working Group Last Call for ECH

> I don't think it's realistic for a generic client (e.g., a standard browser) to omit or falsify this field. Why not? From my understanding the issue that happens in this situation is that the website becomes less reliable for these TLS clients? If so, let that be a problem for the client to

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 8:49 AM A A wrote: > I think we should change outer SNI randomly and periodicity (e.g 1 hours), > if it change fast enough, censor will need to pay a price to block it, > This won't work because the public_name is part of the recovery mechanism for misconfiguration,

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi wrote: > I'd like to understand how the behavior of the latest draft will be under > an adversarial condition. > > One of the things that really excited me about ESNI back in the day was > effectively making it near impossible for countries, like my

Re: [TLS] Working Group Last Call for ECH

I think we should change outer SNI randomly and periodicity (e.g 1 hours), if it change fast enough, censor will need to pay a price to block it,13.03.2024, 23:40, "Amir Omidi" :I'd like to understand how the behavior of the latest draft will be under an adversarial condition.One of the things

Re: [TLS] Working Group Last Call for ECH

I'd like to understand how the behavior of the latest draft will be under an adversarial condition. One of the things that really excited me about ESNI back in the day was effectively making it near impossible for countries, like my home country Iran, from being able to effectively censor the

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena wrote: > On 3/13/24 14:51, Watson Ladd wrote: > > > I'm not sure what problem you want us to solve here. In the case of > > server offering a single domain, an attacker can determine that > > connections to that domain go to the server and cheaply

Re: [TLS] Working Group Last Call for ECH

> Hopefully, some of the people who did the analyses will > chime in on the WGLC though, it'd be good if they had the > time to do that. I am not sure this specific case was covered in our analysis, but I will confer with our co-authors. Best, Karthik > > Cheers, > S. > >> thanks, >> Rob

Re: [TLS] Working Group Last Call for ECH

Hi, "ECH is not in itself sufficient to protect the identity of the server. The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses. However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094] provide mechanisms

Re: [TLS] Working Group Last Call for ECH

On 3/13/24 14:51, Watson Ladd wrote: The reason the public_name exists is so that the connections can all have the same SNI field. Since we can't do what ESNI did, there must be something there and it should all be the same. Could you elaborate a bit on this? Sorry I'm unfamiliar with some

Re: [TLS] Working Group Last Call for ECH

On Tue, Mar 12, 2024 at 10:20 PM Raghu Saxena wrote: > > Are comments restricted strictly to members of the working group? If so, > please ignore this E-Mail. > > I'd previously tried to raise an issue regarding requirements of a > public_name in the ECHConfig in the mailing list [0], and when I

Re: [TLS] Working Group Last Call for ECH

I have risen similar discussion before and have tried to suggest some solutions, but none of them got any support. Here is the previous discuss thread, just FYI https://mailarchive.ietf.org/arch/msg/tls/HlwYX16Y4W2BevKTpI6a81eO1JE/ > On Mar 13, 2024, at 13:20, Raghu Saxena wrote: > > Are

Re: [TLS] Working Group Last Call for ECH

Are comments restricted strictly to members of the working group? If so, please ignore this E-Mail. I'd previously tried to raise an issue regarding requirements of a public_name in the ECHConfig in the mailing list [0], and when I didn't get much response there, even on Github [1], where I

Re: [TLS] Working Group Last Call for ECH

 Ship it. On Tue, Mar 12, 2024, at 09:00, Joseph Salowey wrote: > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the > IESG and send any comments to the list by 31 March 2024. The comments > sent by

Re: [TLS] Working Group Last Call for ECH

I also support seeing the document moving forward. On Tue, Mar 12, 2024, 16:37 Salz, Rich wrote: > I support advancing this document. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >

Re: [TLS] Working Group Last Call for ECH

+1 will do my best to help within the timeline From: TLS on behalf of Salz, Rich Date: Tuesday, 12 March 2024 at 13:37 To: Stephen Farrell , Rob Sayre Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for ECH I support advancing this document

Re: [TLS] Working Group Last Call for ECH

I support advancing this document. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

Hiya, On 12/03/2024 01:25, Rob Sayre wrote: The one that got to me was: "It SHOULD place the value of ECHConfig.contents.public_name in the "server_name" extension. Clients that do not follow this step, or place a different value in the "server_name" extension, risk breaking the retry

Re: [TLS] Working Group Last Call for ECH

The one that got to me was: "It SHOULD place the value of ECHConfig.contents.public_name in the "server_name" extension. Clients that do not follow this step, or place a different value in the "server_name" extension, risk breaking the retry mechanism described in Section 6.1.6 or failing to

Re: [TLS] Working Group Last Call for ECH

On 12/03/2024 00:49, Rob Sayre wrote: On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton wrote: I don't believe there were any changes from draft 13 to 18 that would invalidate security analysis for draft 13:

Re: [TLS] Working Group Last Call for ECH

On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton wrote: > I don't believe there were any changes from draft 13 to 18 that would > invalidate security analysis for draft 13: > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13=draft-ietf-tls-esni-18=--html > Hmm. It does look

Re: [TLS] Working Group Last Call for ECH

On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey wrote: > > This is the working group last call for TLS Encrypted Client Hello [1]. Please indicate if you think the draft is ready to progress to the IESG and send any comments to the list by 31 March 2024. The comments sent by Watson Ladd to the

Re: [TLS] Working Group Last Call for ECH

I don't believe there were any changes from draft 13 to 18 that would invalidate security analysis for draft 13: https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13=draft-ietf-tls-esni-18=--html Chris P. On Mon, Mar 11, 2024 at 3:12 PM Rob Sayre wrote: > On Mon, Mar 11, 2024 at

Re: [TLS] Working Group Last Call for ECH

Hi chairs, I believe ECH is good to go. Chris P. On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey wrote: > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the IESG and > send any comments to the list by 31

Re: [TLS] Working Group Last Call for ECH

Hiya, On 11/03/2024 22:08, Rob Sayre wrote: I think it is ready and can live with the current draft. Same here. The protocol's well baked. The text good enough. I've written code to implement it, done the interop with others, deployed test services and done PoC integrations of my openssl ECH

Re: [TLS] Working Group Last Call for ECH

On Mon, Mar 11, 2024 at 3:08 PM Rob Sayre wrote: > I also believe there was supposed to be some formal proof work done, and > I'm not sure that's complete > Ah, I see this was done: https://dl.acm.org/doi/abs/10.1145/3548606.3559360 So, I guess the only question is whether this needs to be

Re: [TLS] Working Group Last Call for ECH

I think it is ready and can live with the current draft. I agree with Watson Ladd that the ordering is awkward. If you get past that part, it all works, but you have to read the whole thing before you really get it. Then, you must start in the middle to begin your implementation. I guess the