[TLS] Next steps for key share prediction

[David Benjamin <[e-mail]>]

Hi all,

With the excitement about, sometime in the far future, possibly
transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I
thought it would be a good time to remind folks that, right now, *we have
no way to effectively transition between PQ-sized KEMs at all*.

At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which
aims to address this. For a refresher, here are some links:
https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
(Apologies, I forgot to cut a draft-01 with some of the outstanding changes
in the GitHub, so the link above is probably better than draft-00.)

If I recall, the outcome from IETF 118 was two-fold:

First, we'd clarify in rfc8446bis that the "key_share first" selection
algorithm is not quite what you want. This was done in
https://github.com/tlswg/tls13-spec/pull/1331

Second, there was some discussion over whether what's in the draft is the
best way to resolve a hypothetical future transition, or if there was
another formulation. I followed up with folks briefly offline afterwards,
but an alternative never came to fruition.

Since we don't have another solution yet, I'd suggest we move forward with
what's in the draft as a starting point. (Or if this email inspires folks
to come up with a better solution, even better! :-D) In particular,
whatever the rfc8446bis guidance is, there are still TLS implementations
out there with the problematic selection algorithm. Concretely, OpenSSL's
selection algorithm is incompatible with this kind of transition. See
https://github.com/openssl/openssl/issues/22203

Given that, I don't see a clear way to avoid *some* way to separate the old
behavior (which impacts the existing groups) from the new behavior. The
draft proposes to do it by keying on the codepoint, and doing our future
selves a favor by ensuring that the current generation of PQ codepoints are
ready for this. That's still the best solution I see right now for this
situation.

Thoughts?

David