search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
231 stars 56 forks source link

Explain when clients can remember rejected ECH. Fixes #604 #609

Open ekr opened 4 months ago

ekr commented 4 months ago

@martinthomson

dennisjackson commented 4 months ago

Reading the discussion, are you sure the complexity of doing this is worth the gain? The principle mechanism server operators have for controlling ECH attempts is updating their DNS records. Presuming they can do that reasonably quickly, aren't most clients going to maintain an open connection for the relevant time period anyway? How long is the window in which we won't have an open usable connection (with ECH or not) but we'd be willing to remember the past ECH failure/retry-config for?

I'd also point out that we also can't assume that ECHConfigs always come from DNS for the purposes of working out an expiration time. It could be that applications are configured by some other out of band mechanism, or even that they deliberately use a known-bad config and intend to rely on a provided retry-config.

ekr commented 4 months ago

The complexity of specifying it or the complexity of implementing it? Right now I read the spec as just prohibiting it.

WRT multiple connections, the case I am concerned about is HTTP connection sharding when you might have 4 or so concurrent connections. I suppose we can just say that this is a reason to use H2 or H3.

WRT not-DNS, I think we could practically just limit this kind of memory to DNS.

Anyway, i don't feel strongly about this, and we could always relax this restriction later, so if others aren't enthusiastic, we can just close this unchanged.

ekr commented 4 months ago

I think this may need a little more bake time. I'm going to ship the next version without it and hopefully we can refine over the next few weeks, or alternately decide we don't need it.

sftcd commented 4 months ago

On 04/03/2024 02:18, Eric Rescorla wrote:

I'm going to ship the next version

Yes, shipping a version good enough for WGLC and then IETF LC is the right plan. There'll be plenty of chances for fixing wording at those stages.

S.

ekr commented 1 month ago

Revisiting this....

  1. I think we should make the "single retry" change. I split that into #616. There's no reason that should happen.

  2. I'm less sure about the "you can remember" stuff, but on balance I think it's worth it. I've updated it to take @bemasc's comments and now I think it's correct. @martinthomson @bemasc @dennisjackson @davidben ?

ekr commented 1 month ago

@martinthomson how's this