Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and me) about a suggestion about one way to potentially improve the performance (in the 'the server hasn't upgraded yet' case), and asked if we should add that suggestion to our draft. It occurs to me that this suggestion is equally applicable to the pure ML-KEM draft (and future PQ drafts as well); hence putting it in our draft might not be the right spot.
Here's the core idea (Matt's original scenario was more complicated): * Suppose we have a client that supports both P-256 and P256+ML-KEM. What the client does is send a key share for P-256, and also indicate support for P256+ML-KEM. Because we're including only the P256 key share, the client hello is short * If the server supports only P256, it accepts it, and life goes on as normal. * If the server supports P256+ML-KEM, what Matt suggested is that, instead of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then continue as expected and end up negotiating things in 2 round trips. Hence, the non-upgraded scenario has no performance hit; the upgraded scenario does (because of the second round trip), but we're transmitting more data anyways (and the client could, if it communicates with the server again, lead off with the proposal that was accepted last time). Matt's suggestion was that this should be a SHOULD in our draft. My questions to you: a) do you agree with this suggestion, and b) if so, where should this SHOULD live? Should it be in our draft? The ML-KEM draft as well (assuming there is one, and it's not just a codepoint assignment)? Another RFC about how to handle large key shares in general (sounds like overkill to me, unless we have other things to put in that RFC)? Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
