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

[David Benjamin <[e-mail]>]

I think you're several discussions behind here. :-P I don't think
draft-ietf-tls-hybrid-design makes sense here. This has nothing to do with
hybrids, but anything with large key shares. If one were to do Kyber on its
own, this would apply too. Rather, per the discussion at IETF 118, the WG
opted to add some clarifications to rfc8446bis in light of draft-00.

It has also turned out that:
a) RFC 8446 actually already defined the semantics (when I wrote draft-00,
I'd thought it was ambiguous), though the clarification definitely helped
b) The implementation that motivated the downgrade concern says this was
not bug from misunderstanding the protocol, but an intentional design
decision

Given that, the feedback on the list and
https://github.com/davidben/tls-key-share-prediction/issues/5, I concluded
past-me was overthinking this and we can simply define the DNS mechanism
and say it is the server's responsibility to interpret the preexisting TLS
spec text correctly and pick what it believes is a coherent selection
policy. So draft-01 now simply defines the DNS mechanism without any
complex codepoint classification and includes some discussion of the
situation in Security Considerations, as you noted.

Of what remains in Security Considerations, the random client MAY is
specific to this draft and does not make sense to move. The server NOT
RECOMMENDED is simply restating the preexisting implications of RFC 8446
and the obvious implications of believing some options are more secure than
others. If someone wishes to *replicate* it into another document, they're
welcome to, but I disagree with *moving* it. In the context of the
discussion in that section, it makes sense to restate this implication
because this is very relevant to why it's okay for the client to use DNS to
influence key shares.

David

On Wed, Mar 20, 2024 at 6:08 AM Kampanakis, Panos <[e-mail]> wrote:

> Hi Scott, David,
>
>
>
> I think it would make more sense for the normative language about Client
> and Server behavior (section 3.2, 3.4) in
> draft-davidben-tls-key-share-prediction-00 (
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> ) to go in draft-ietf-tls-hybrid-design. These are now discussed in the Sec
> Considerations of draft-davidben-tls-key-share-prediction-01, but the
> “SHOULD” and “SHOULD NOT” language from -00 section 3.2 and 3.4 ought to be
> in draft-ietf-tls-hybrid-design.
>
>
>
> I definitely want to see draft-davidben-tls-key-share-prediction move
> forward too.
>
>
>
> Rgs,
>
> Panos
>
>
>
> *From:* TLS <[e-mail]> *On Behalf Of * David Benjamin
> *Sent:* Tuesday, March 19, 2024 1:26 AM
> *To:* Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [EXTERNAL] [TLS] A suggestion for handling large key shares
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> > 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.
>
>
>
> 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
>
>