How to retry in ECH is ambiguous

[davidben]

Not sure what the right answer is, or whether this belongs in this draft, or some upper layer document. (Alas, though I'm not even sure whether those upper layer documents exist... SVCB? Part of HTTP?) When the recovery flow triggers, we are supposed to "retry the handshake with a new transport connection".

The transport connection is mostly out of TLS's scope, but somewhere we should decide whether this means...

• Do you connect with the exact same IP?
• Do you connect with the same SVCB record, but other IPs within that route are in scope?
• Do you connect anew and we just say, meh, this is a recovery mechanism so our aim is just to work most of the time?
• Or maybe we'll learn this is a problem and we need to jam the retry in the same connection (big protocol change, shifts some complexity from upper layers into TLS)
• What happens with proxies, which typically make DNS queries for you? Should we ever decide to integrate SVCB fetching into HTTP CONNECT, the answer here will have implications for that scheme.

Hopefully, with initial experiments, we'll understand this better. But filing this now so we don't forget to address it later.

[orangepizza]

I don't think it's in scope of this but TLS 1.3 itself(rfc8446)?

[davidben]

Why RFC 8446? RFC 8446 and this document both have the same opinions about how to set up the transport connection, which is to say, none. It also cannot usefully talk about ECH retries, because ECH retries don't exist before this extension.

[chris-wood]

@davidben I think the most we can say in this document is option (3), which is to say that it's recovery and implementations can do what they want with the guidance to make things work the best they can. It might be helpful to have a higher-level document describing behavior that has emerged in Firefox and Chrome (cc @dennisjackson), but that seems orthogonal and much more involved than what we can probably reasonable accomplish here.

[dennisjackson]

I'd prefer to have some 'SHOULD' guidance here for implementers and a pointer to the advice in draft-ietf-tls-svcb-ech. It would be good to clarify the interaction between retry ECHConfigs and alternative ECHConfigs+IP hints for example. Something like:

• When provided with an ECHConfig via a TLS retry extension, you SHOULD use the same IP.
• If the retry fails, follow draft-ietf-tls-svcb-ech (if in use).