Subject: [TLS] ECH - handling retry config with different public name?

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Nov 2021 14:17:56 +0000

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.

---

From: David Benjamin <[email-masked]>
Date: Fri, 5 Nov 2021 11:20:19 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 07 Nov 2021 09:20:55 +1100

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 
> <[email-masked]> wrote:
>> 
>> Hiya,
>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Nov 2021 22:47:29 +0000

Hiya,

On 06/11/2021 22:20, Martin Thomson wrote:
> I assume that you might add "just once" there.  Or at least a limited
> number 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.
> 
>> 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?
>> 
>>> 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 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>