Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Sebastian Andrzej Siewior
On 2020-01-13 11:23:35 [+], Matt Caswell wrote: > The current behaviour is that the first key share we see that also > exists in our supported groups list is the one that we use. There isn't > a way at the moment to configure things in order to specify a preference > order. > > https://github.

Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Hubert Kario
On Friday, 10 January 2020 23:41:20 CET, Sebastian Andrzej Siewior wrote: Hi, gnutls-cli sends by default (in the supported groups extension) `secp256r1' first and later `x25519'. The key_share extension contains a key for both types. The server has both types configured both groups and `x25519'

Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Matt Caswell
On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote: > gnutls-cli sends by default (in the supported groups extension) > `secp256r1' first and later `x25519'. The key_share extension contains a > key for both types. The server has both types configured both groups and > `x25519' comes first. >

Enforcing group / key_share order in TLS1.3

2020-01-10 Thread Sebastian Andrzej Siewior
Hi, gnutls-cli sends by default (in the supported groups extension) `secp256r1' first and later `x25519'. The key_share extension contains a key for both types. The server has both types configured both groups and `x25519' comes first. The handshake however ends up with `secp256r1'. Is there a way