Re: [TLS] A suggestion for handling large key shares

[Bas Westerbaan <[e-mail]>]

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=
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>