Hiya,
On 06/11/2021 22:20, Martin Thomson wrote:
I assume that you might add "just once" there. Or at least a limitednumber of times.
Right. I think that's in the spec already. Cheers, S.
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:_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tlsHiya, 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
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
