[gnutls-devel] GnuTLS | Inconsistent/illogical behaviour in GnuTLS server when selecting group for the connection (#1713)

[Read-only notification of GnuTLS library development activities]

Alicja Kario (@mention me if you need reply) created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1713



When GnuTLS server receives a connection from a client that advertises modified lists of groups and key shares, the behaviour of the server is not consistent:

(* - means that the group was also sent in the key_share)

  *X25519MLKEM768:SECP256R1MLKEM768 = X25519MLKEM768 (GOOD)
  X25519MLKEM768:*SECP256R1MLKEM768 = X25519MLKEM768 (not good: not
using a sent key_share)
  X25519MLKEM768:*SECP256R1MLKEM768:X25519:P-256:P-384 = X25519 (BAD:
not hybrid)
  *X25519MLKEM768:*SECP256R1MLKEM768:X25519:*P-256:P-384 = X25519
(BAD: not hybrid)
  *X25519MLKEM768:SECP256R1MLKEM768:*P-256:P-384 = P-256 (BAD: not hybrid)
  *SECP256R1MLKEM768:*P-256:P-384 = P-256 (BAD: not hybrid)
  *SECP256R1MLKEM768:P-256:P-384 = P-256 (BAD: not hybrid and not key_share)
  *X25519MLKEM768:SecP256r1MLKEM768:SecP384r1MLKEM1024:X25519:secp256r1:X448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192 = X25519MLKEM768 (GOOD: why?)
  *X25519MLKEM768:SecP256r1MLKEM768:SecP384r1MLKEM1024:X25519:secp256r1:X448:secp521r1:secp384r1 = X25519 (BAD: not hybrid, but the difference was just omitting FFDHE)


OpenSSL fixed this issue by introducing the ``/`` syntax in groups, allowing the user to specify "try to negotiate those groups first, even at a cost of HRR", so for example:
``X25519MLKEM768:SECP256R1MLKEM768:SECP384r1MLKEM1024/X25519:P-256:P-384`` would cause the server to negotiate hybrid post-quantum groups, if at all supported by the client, even if the client did advertise just X25519 key share. The same syntax without ``/`` would negotiate the first group that is in key_shares of ClientHello and is supported by server.

The nice thing about this syntax is that allows the user the flexibility to decide if they want to prefer hybrid or pure post-quantum algorithms over classical ones, or if they want to prioritise latency by prioritising key_shares that are already there.

If we don't want this level of flexibility, I think the group selection still should at least prefer hybrid post-quantum groups over anything else (at the very least, when they are advertised in key_share)

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1713
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20250604/7d343179/attachment-0001.html>