On Fri, Jun 25, 2021 at 8:45 PM Stephen Farrell
wrote:
>
> So I guess we're landing on "if the client got a ticket via
> a session that successfully used ECH, it MUST send a fresh
> ECH when using that ticket"? That's ok I guess, but maybe
> some more detail is needed...
>
> On 25/06/2021 17:01,
So I guess we're landing on "if the client got a ticket via
a session that successfully used ECH, it MUST send a fresh
ECH when using that ticket"? That's ok I guess, but maybe
some more detail is needed...
On 25/06/2021 17:01, David Benjamin wrote:
1. Either this layer knows how to set up TLS,
In addition to needing to send ECH in case the server declines resumption,
we need to keep the ticket under encryption anyway. Without changing how
resumption works, there are a couple of attacks on cleartext tickets:
1. If the tickets from two backend servers are distinguishable from each
other,
On Fri, Jun 25, 2021 at 7:21 AM Stephen Farrell
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 [
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
