On Thu, Mar 7, 2024 at 2:56 PM David Benjamin <david...@chromium.org> wrote: > > 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
Is that asking whether or not we want adoption? I want adoption. > > 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? I think letting the DNS signal also be an indicator the server implements the correct behavior would be a good idea. Sincerely, Watson ---- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
