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 list [2] on 17 February 2024 will be considered last
call
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
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
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
* …and now I'm coming around to the idea that we don't need to do anything
special to account for the "wrong" server behavior. Since RFC8446 already
explicitly said that clients are allowed to not predict their most preferred
groups, we can already reasonably infer that such servers
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:
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
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
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
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
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
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
12 matches
Mail list logo
