On Wed, Oct 16, 2024 at 10:22 AM Paul Wouters <p...@nohats.ca> wrote: > > On Wed, 16 Oct 2024, Martin Thomson wrote: > > > A retry fallback happens with the public name. The server that offers ECH > > lists a public name. If the ECH config (for key A) turns out to be > > unusable, the server offers a regular handshake with that public name, > > where it offers retry_configs. > > > > So, while the connection might attempt a connection with ech.example, the > > connection is "completed" with public.example. The process of validating > > that connection doesn't really involve ECH, it's just an ordinary > > certificate. But the DNS record for ech.example established that *for the > > purposes of negotiating ECH* public.example is authorized to provide a > > config. That part is independent of the keys that are used and therefore > > OK to have immutable. > > Ohhh. now I get it! It solves my misunderstanding and my concern about > being dead in the water if a key was lost. Thanks for this answer! > > Now please add this clearly to the document :) > > Thanks Ekr for the DNS explanation too. I think it would still be good > to suggest .invalid for the server to keep things as simple as possible.
Just to clarify: this is about greasing with mandatory extensions by advertising the configurations with public names that are not ones the server "responds to". On reading this I'm not sure what is meant by "not responds to": send a TLS error about SNI not being right? Close the connection? I think using .invalid is a bad idea because the point of greasing is to stress proper protocol negotiation. A client that could distinguish unusable configs by looking at the name is not properly implementing the mandatory extension logic. Sincerely, Watson > > Paul > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
