[TLS] Re: PSK identifier (and binder) lengths in the TLS 1.3 outer ECH?

I don't think the concern of making the backend server's ServerHello valid
for the ClientHelloOuter is *in itself* a problem. It's already the case
that the ClientHelloInner might have different cipher suites, named groups,
or anything else. The client processing the ServerHello will know what's
the ClientHelloInner and that the ServerHello targeted it, so it can still
evaluate the protocol correctly. It only matters if, as the document
suggests, you're trying to make ECH and ECH GREASE look similar:

> This would appear to a network observer as if the server were sending
this extension without solicitation, which would violate the extension
rules described in [RFC8446].

Even there, I also do not see why the outer and inner length must match.
I guess if you're not sure what ticket size the TLS server issues, using
the same length gives you a representative value to copy??

Keep in mind, all of this is in the context of a SHOULD:

> When offering a PSK in ClientHelloInner, clients SHOULD send a GREASE
"pre_shared_key" extension in the ClientHelloOuter to make it appear to the
network as if the extension were negotiated properly.

I think ignoring this SHOULD is fine and SHOULD was perhaps too strong.
It's a bit of fuss and doesn't even achieve the goal of making ECH and
ECH GREASE similar. We don't send a fake outer PSK extension at all. I
remember, in discussions, thinking this was pretty pointless. In other ECH
vs ECH GREASE scenarios, there was some plausible (if pretty
overengineered) purpose to making them look similar. IIRC we were actually
able to argue that, but for the distribution of public names and such, the
mechanism itself actually distinguish things.

But here, it falls over pretty quickly. Suppose you took a ClientHello with
a PSK in it and replayed it exactly as-is. In a normal, non-ECH
ClientHello, you would expect the server to continue to accept the PSK. Now
suppose you flipped a bit in the binder and replay it. You would expect the
server to try to accept the PSK, notice the binder is wrong, and abort the
handshake <https://www.rfc-editor.org/rfc/rfc9846.html#section-4.3.11-8>.

Now let's consider ECH with PSKs on the inside and GREASE PSKs on the
outside. You take the ClientHello and replay it. The server accepts the
inner PSKs again and all looks fine. Now you flip a bit in the GREASE
binder and replay it. Several things now happen:
1. The ECH encryption is now broken because ClientHelloOuterAAD is wrong.
2. The server handshakes with ClientHelloOuter instead
3. ClientHelloOuter's PSKs are all fake, so you will see a ServerHello that
doesn't accept any PSKs at all

Those are different behaviors, so we haven't actually made them similar
anyway.

On Thu, Jul 16, 2026 at 11:59 AM Viktor Dukhovni <[email protected]>
wrote:

> Can anyone shed a glimmer of light on the below?
>
> On Sun, Jul 12, 2026 at 04:10:47AM +1000, Viktor Dukhovni wrote:
>
> > In <https://datatracker.ietf.org/doc/html/rfc9849#name-grease-psk> one
> reads:
> >
> >     The client generates the extension payload by constructing an
> >     OfferedPsks structure (see [RFC8446], Section 4.2.11) as follows. For
> >     each PSK identity advertised in the ClientHelloInner, the client
> >     generates a random PSK identity with the same length. It also
> generates
> >     a random, 32-bit, unsigned integer to use as the
> obfuscated_ticket_age.
> >     Likewise, for each inner PSK binder, the client generates a random
> >     string of the same length.
> >
> > It is reasonably clear why the outer PSK count should be at least the
> > inner PSK count, making the backend server's SH valid per protocol.
> >
> > What is far from clear is why the lengths must match.  Especially for
> > external PSKs, where the identity length can distinguish some clients
> > from others, or for resumption tickets bearing certificate chains, that
> > are reflected in the certificate size, why must the outer length leak
> > the inner length?  The reason is not obvious to me.
> >
> > Also why can't the outer PSK count exceed the inner PSK count?
>
> --
>     Viktor.  🇺🇦 Слава Україні!
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]