Hi Scott, I generally agree with David, in particular that the keyshare prediction draft is the way forward.
There is a different use-case for your mechanism, which you didn't mention: it's less likely to trip over buggy servers / middleboxes. We use it as the default mechanism to talk to our customer's origins. https://blog.cloudflare.com/post-quantum-to-origins Thanks to Chrome's efforts, for browsers, we luckily don't need to use this slower mechanism. One inline comments down below. Best, Bas On Tue, Mar 19, 2024 at 5:47 AM Scott Fluhrer (sfluhrer) <sfluhrer= 40cisco....@dmarc.ietf.org> wrote: > 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 > The roundtrip is quite a bit more costly than the extra kilobyte of upload with respect to latency. > (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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
