On Fri, Jun 25, 2021 at 7:21 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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). > TLS session resumption is soft state, so I believe the correct response here is to send ECH. Otherwise, the server cannot properly respond if it is not willing to accept the ticket. The only real alternative here is to have some way for the server to indicate that it has forgotten the ticket and the client needs to do a full handshake and *now* do ECH. But of course, that's not something that's currently specified and isn't really a great fit for anything in the protocol, though I guess HRR is closest. -Ekr > 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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
