[gnutls-devel] GnuTLS | can't send mlkem768x25519 and x25519 key shares together; would rather see both sent with x25519 value reused (#1763)

[Read-only notification of GnuTLS library development activities]

Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1763



## Description of problem:

If I enable both mlkem768x25519 and x25519 with `@SYSTEM:-GROUP-ALL:+GROUP-X25519-MLKEM768:+GROUP-X25519`, they're both present in Supported Groups, but only one share, the X25519-MLKEM768 one, gets sent, despite that sending two shares is supposed to be the default behaviour: `GNUTLS_KEY_SHARE_TOP2 : Generate key shares for the top-2 different groups which are enabled. For example (ECDH + x25519). This is the default.`

The code that skips sending the x25519 one is likely the `if (pk_types_overlap(group, selected_groups[j])) break;` from https://gitlab.com/gnutls/gnutls/-/merge_requests/1892/diffs?commit_id=1065654c828eaad638fab3c4af7096ab0c8ee615

This ticket is related to https://gitlab.com/gnutls/gnutls/-/issues/1710 and https://gitlab.com/gnutls/gnutls/-/issues/1551, but I'm filing it separately because fixing this particular quirk in isolation might be simpler than any of these two.

## Version of gnutls used:

3.8.10

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

RHEL

## How reproducible:

reliably

Steps to Reproduce:

 * `tcpdump ...`
 * `gnutls-cli --priority @SYSTEM:-GROUP-ALL:+GROUP-X25519-MLKEM768:+GROUP-X25519 ...`
 * inspect the ClientHellos

## Actual results:

Both key shares are correctly advertised as supported, but only one is being offered. A server offering just X25519 will HelloRetryRequest back, gnutls will send a second ClientHello with a X25519 key share, the connection will be established, but with an extra roundtrip.

## Expected results:

Both key shares are sent. A server offering just X25519 will use the X25519 key share, the connection will be established with no extra roundtrip.

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/16 3.2 suggests it's legal to reuse the single X25519 value across both key shares instead of generating a second one, which would make it a preferred outcome due to the performance considerations.

Would also be fun if servers were smart enough to pick apart the hybrid key share and use the X25519 part of it with no HRR; fun, but, I presume, not spec-compliant.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1763
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/20251120/7cd6db97/attachment.html>