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

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

> On Fri, Aug 14, 2026 at 08:40:49AM -0400, David Benjamin wrote:
>
> > > 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.
>
> That's perhaps easier for Chromium if the MLKEM keyshare prediction is
> unconditional.  In OpenSSL the configuration file and/or application
> esttings can tweak keyshare prediction to give a CH size in the F5
> danger-zone, and I don't know whether there's any reason to still care.
>
> Are there still somewhere out of view users lovingly maintaining and
> getting useful service from unpatched F5's dating back to ~2014?
>

I mean, I too have to deal with more than just Chromium with BoringSSL.
We're not OpenSSL, but my employer has amassed more than a couple projects
over the years. :-p Including, I'm sure, folks who still have legacy curve
configs that don't include ML-KEM. But our main way to validate a client
configuration is with Chromium, and I've gotten all the Chromium signal
about old F5 that I ever will at this point.

If it turns out there's an unpatched F5 box that then breaks with a random
BoringSSL client carrying over an old config, I'm perfectly happy to have
to tell them to turn PQC on for better security AND compatibility.

Dunno if this one implementation counts as "broader movement", but, well,
this is all I can offer you from my corner of the world. :-)

David

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