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

[tirumal reddy <[e-mail]>]

On Tue, 19 Mar 2024 at 15:27, David Benjamin <[e-mail]> wrote:

> > 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.
>
> I assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah,
> a server which aims to prefer P256+ML-KEM over P256 should, well, prefer
> P256+ML-KEM over P256. :-) See the discussions around
> draft-davidben-tls-key-share-prediction. In particular, RFC 8446 is clear
> on the semantics of such a ClientHello:
>
>    This vector MAY be empty if the client is requesting a
>    HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a
>    group offered in the "supported_groups" extension and MUST appear in
>    the same order.  However, the values MAY be a non-contiguous subset
>    of the "supported_groups" extension and MAY omit the most preferred
>    groups.  Such a situation could arise if the most preferred groups
>    are new and unlikely to be supported in enough places to make
>    pregenerating key shares for them efficient.
>
> rfc8446bis contains further clarifications:
> https://github.com/tlswg/tls13-spec/pull/1331
>
> Now, some servers (namely OpenSSL) will instead unconditionally select
> from key_share first. This isn't wrong, per se. It is how you implement a
> server which believes all of its supported groups are of comparable
> security level and therefore prioritizes round trips. Such a policy is
> plausible when you only support, say, ECDH curves. It's not so reasonable
> if you support both ECDH and a PQ KEM. But all the spec text for that is in
> place, so all that is left is that folks keep this in mind when adding PQ
> KEMs to a TLS implementation. A TLS stack that always looks at key_share
> first is not PQ-ready and will need some changes before adopting PQ KEMs.
>
> Regarding the other half of this:
>
> > 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
>
> I don't think this is a good tradeoff and would oppose such a SHOULD here.
> PQ KEMs are expensive as they are. Adding a round-trip to it will only make
> it worse. Given the aim is to migrate the TLS ecosystem to PQ, penalizing
> the desired state doesn't make sense. Accordingly, Chrome's Kyber
> deployment includes X25519Kyber768 in the initial ClientHello. While this
> does mean paying an unfortunate upfront cost, this alternative would
> instead disincentivize servers from deploying post-quantum protections.
>
> If you're interested in avoiding the upfront cost, see
> draft-davidben-tls-key-share-prediction-01. That provides a mechanism for
> clients to predict more accurately, though it's yet to even be adopted, so
> it's a bit early to rely on that one. Note also the Security Considerations
> section, which further depends on the server expectations above.
>

The scenario of handling large key sizes is disussed in
https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-02.html#section-4

-Tiru


>
> David
>
> On Tue, Mar 19, 2024 at 2:47 PM 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 (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
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>