Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan <[e-mail]>]

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