gnutls-cli reports bad values for the "Ephemeral EC Diffie-Hellman parameters" with hybrid ML-KEM

Description of problem:

When gnutls-cli is used for a connection that negotiates one of the hybrid groups with ML-KEM, the values reported by it are invalid/incorrect

Version of gnutls used:

gnutls-3.8.10-1.el10.x86_64

Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

RHEL

How reproducible:

  1. Start TLS server with support for hybrid ML-KEM groups (like x25519mlkem768)
  2. Connect with gnutls-cli --resume

Actual results:

...
- Status: The certificate is trusted. 
- Description: (TLS1.3-X.509)-(HYBRID-X25519-MLKEM768)-(ML-DSA-44)-(AES-256-GCM)
- Session ID: EE:A3:8B:EA:49:5A:AB:86:89:29:D8:55:AB:E1:D4:8B:D8:22:90:52:E9:8C:98:E6:86:B6:00:A3:10:51:EA:CE
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: (null)
 - Curve size: 0 bits
- Version: TLS1.3
- Server Signature: ML-DSA-44
- Cipher: AES-256-GCM
- MAC: AEAD
- Options:
- Channel bindings
 - 'tls-unique': not available
 - 'tls-server-end-point': 
 - 'tls-exporter': baa413b2c015a4ee708d1725a30bcf029c55a056cbad32d1f7e452589edbf4b2
- Handshake was completed
client hello
- Disconnecting


- Connecting again- trying to resume previous session
Resolving 'localhost:4433'...
Connecting to '::1:4433'...
- Description: (TLS1.3-X.509)--(AES-256-GCM)
- Session ID: EE:A3:8B:EA:49:5A:AB:86:89:29:D8:55:AB:E1:D4:8B:D8:22:90:52:E9:8C:98:E6:86:B6:00:A3:10:51:EA:CE
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: (null)
 - Curve size: 0 bits
- Version: TLS1.3
- Cipher: AES-256-GCM
- MAC: AEAD
- Options:
- Channel bindings
 - 'tls-unique': not available
 - 'tls-server-end-point': 
 - 'tls-exporter': 95380f62755f0e45c75ae786a5fb77bf95e8a4323f9687eb81cb280d2d514f77
- Resume Handshake was completed
*** This is a resumed session

- Simple Client Mode:

- Sent: 13 bytes
- Received[13]: server hello

Expected results:

  1. Both connections should either omit the "Ephemeral EC Diffie-Hellman parameters" or update them so that they report the used KEX method correctly
  2. the resumed session "Description:" field doesn't report that it is using (HYBRID-X25519-MLKEM768), despite the server performing a psk_dhe_ke resumption, not a psk_ke (both pre_shared_key and key_share are present in the ServerHello message)