On Tue, 19 Mar 2024 at 15:27, David Benjamin <david...@chromium.org> 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= > 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 (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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
