I assume that you might add "just once" there. Or at least a limited number of times. Infinite regress seems like something worth avoiding. outer1 -> outer2 -> outer1 is likely not a great outcome.
On Sat, Nov 6, 2021, at 02:20, David Benjamin wrote: > That's my inclination as well. It's an odd thing for a server to do, > but it seems fine to just retry with the new config without much fuss? > > On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> Hiya, >> >> Bit of a corner case I'm not sure about. Apologies >> if this has come up before. >> >> The scenario: >> >> - inner SNI is inner.example >> - ECHConfig from inner.example's DNS has outer.example >> as public_name >> - client authenticates with ClientHelloOuter and the >> ServerHello contains retry_configs with one ECHConfig >> that has a public_name of another.example >> - client decides to retry and a similar thing happens >> (authenticates with ClientHelloOuter) but this time >> with public_name of yetanother.example >> - rinse/repeat until the client is fed up with retries >> or manages to authenticate using ClientHelloInner if >> ECH eventually works >> >> My question is: should the client care about those >> changes in public_name or not? I think the answer is >> "not" but wanted to check. >> >> Ta, >> S. >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
