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

On Fri, Aug 14, 2026, 01:11 Viktor Dukhovni <[email protected]> wrote:

> On Thu, Aug 13, 2026 at 07:18:11PM -0400, David Benjamin wrote:
>
> > 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. [...]
>
> Thanks for the validation.  Though my plans in that direction haven't
> yet materialised in the form of a pull request (which could I guess
> encounter some pushback when it lands) I am planning drop PSK grease
> from the outer CH.  This substantially simplifies the F5 padding
> bookkeeping, which we're still keeping for the moment.  When there's
> a broader movement to drop the F5 workaround padding, I'd love to drop
> that as well.
>

Oh, that's a good reminder. I had meant to go remove it. Now that
ClientHellos have ML-KEM key shares, this is moot because they're never in
the problem range anymore. :-)

I would hope, by now, all the F5s have been updated, but the failure
condition was a timeout, which made measurements difficult. But happily now
it doesn't matter. The bookkeeping is indeed a pain.

David

>

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