[TLS] Re: PSK identifier (and binder) lengths in the TLS 1.3 outer ECH?
Viktor Dukhovni <[email protected]>
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
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.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]