Hiya,
If a client established a session to foo.example.com using ECH with a public_name of example.com, what ought the client put in the SNI when resuming? Ignoring ECH, 8446 seems to imply one ought put in foo.example.com [1] but that'd defeat the purpose of ECH. If one omits SNI, that would likely be hard to handle for a client-facing server when it tries to route to a good split-mode backend. The same could be true even if example.com is included as the SNI. I guess the client could do ECH again, but that'd also be odd, as it'd require asymmetric crypto when resuming (which I guess is a lot of the point of tickets), and depending on ticket ages vs. ECHConfig key rotation times, might cause interesting failures for a library client that can't do fresh DNS queries from within the library (and might never see the TTL of the HTTPS/SVCB RR in any case). Am I missing something obvious? If not, what's best here? (And we should probably have some text in the draft on this too.) Cheers, S. PS: I guess if the inner and outer ALPNs differed in the original CH, similar issues might arise for a client-facing server, in terms of figuring out the right backend to which the resumed session should be routed, if routing were based on e.g. the inner ALPN. [1] https://datatracker.ietf.org/doc/html/rfc8446#page-57
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
