On Wed, Oct 16, 2024, at 13:15, Paul Wouters wrote: >> Suppose that the server was using key A and publishes an appropriate >> record. It then loses the key and starts using B. If a client comes >> in using key A, the server is supposed to follow the ECH configuration >> correction procedure in S 6.1.6 and provide a retry configuration with >> key B. The client will then retry with B. This isn't an outage, though >> it has a negative performance impact, which is why it's best to have >> keys overlap. > > I am confused how this can happen "securely" if the only way to prove > this is not a malicious attack is to use the private key that was lost? > > I guess I am confused about: > > If the server provided "retry_configs" and if at least one of the > values contains a version supported by the client, the client > can regard the ECH keys as securely replaced by the server. It > SHOULD retry the handshake with a new transport connection, > using the retry configurations supplied by the server. > > The retry_configs contain ECHConfigList. The ECHConfigList contains > ECHConfig structures which it clains "allows a server to support multiple > versions of ECH and multiple sets of ECH parameters". > > But either these are confirmed by key A, which was lost, or these are > indistinguishable from an attacker pretending to have lost key A and > accepted? I must be missing something here?
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. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
