For TLS on the Web it would be ideal if we can find a single[1] hybrid which we can all be happy with because that will make keyshare negotiation easier.
To wit, BoringSSL, when SSL_OP_CIPHER_SERVER_PREFERENCE is set, will pick the group based on the supported_groups that the client sends. Thus, in this case if the server prefers X25519 over P-256, and a client sends a P-256 keyshare but also advertises support for X25519, the server will send an HRR to get an X25519 agreement. In practice this is not a problem, because X25519 has become the de facto standard. Before that was the case, many clients sent both a P-256 and X25519 keyshare. The PQ hybrid situation is more painful. Suppose we end up with two essentially equivalent hybrids, say P-256+Kyber768 and X25519+Kyber768, and different servers have a different preference. Then clients are forced to either send both keyshares or suffer an HRR. Of course, we can change the server logic, but it isn't simple. An OpenSSL server, for instance, with SSL_OP_CIPHER_SERVER_PREFERENCE set, will accept a keyshare it supports even if the client announces support for another group that the server prefers. This has a disadvantage[2]: if a client sends a X25519 keyshare but announces support for a PQ keyshare, we would want the server to HRR to establish a PQ connection (as BoringSSL will do if the PQ groups are preferred.) Best, Bas [1] That shouldn't prevent us from assigning code points for many hybrids. [2] Thanks to David Benjamin for pointing that out to me. On Tue, Aug 23, 2022 at 10:30 AM Kris Kwiatkowski <k...@amongbytes.com> wrote: > > On 23/08/2022 01:39, Martin Thomson wrote: > > On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote: > > As X25519 is not FIPS-approved, the lab won't be able to test it, > > OK, hypothetical question, but maybe an important one. > > Why would a certification lab care? We compose secrets with non-secrets all > the time, so even if X25519 were replaced with a public value, as long as > Kyber is approved, can they not proceed to certify on the basis of the > strength of the Kyber algorithm and its implementation? > > FIPS lab won't care, as I've mentioned Kyber+x25519 can be certified when > Kyber is FIPS-approved. The customers may > care. As FIPS developer, I would like to be able to provide hybrid > construction in which both algorithms are FIPS > approved, so that in case Kyber gets broken, the key exchange is still is > safe (as per FIPS standards), rather then > Kyber gets broken and now you are not FIPS compliant. > Makes sense? > > Or, more realistically, maybe the composition method can be approved, just as > composing a secret with "chickenchickenchicken" can be rendered safe. That > way, composing with an arbitrary primitive might be considered safe if the > composition method is approved. > > Composition method is an approved technique, see SP800-56Cr2 (point 2). > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://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
