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.
Paul
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
