TLS 1.3: SessionTicket: Enable kex change mode check when resumption

[yuhaoth]

From RFC 8446 section 4.2.9

   In order to use PSKs, clients MUST also send a
   "psk_key_exchange_modes" extension.  The semantics of this extension
   are that the client only supports the use of PSKs with these modes,
   which restricts both the use of PSKs offered in this ClientHello and
   those which the server might supply via NewSessionTicket.
   A client MUST provide a "psk_key_exchange_modes" extension if it
   offers a "pre_shared_key" extension.  If clients offer
   "pre_shared_key" without a "psk_key_exchange_modes" extension,
   servers MUST abort the handshake.  Servers MUST NOT select a key
   exchange mode that is not listed by the client.  This extension also
   restricts the modes for use with PSK resumption.  Servers SHOULD NOT
   send NewSessionTicket with tickets that are not compatible with the
   advertised modes; however, if a server does so, the impact will just
   be that the client's attempts at resumption fail.

We should add key exchange mode check for ticket. ticket_flags of mbedtls_ssl_session is used for it.
In last flight connection, we should add below action

• On client side, copy advertised kex modes to ticket_flags of received tickets.
• On server side, check if the advertised modes can support session tickets, if no, do not send session tickets.
• On server side, generate tickets with the advertised modes and set tickets in ticket callback.

In resumption connection,

• On client side, filter the tickets with advertised modes
• On server side, check the advertised modes and ticket flags, if it does not match, fall into 1-RTT

[yuhaoth]

#6486 is important for this topic.

[lpy4105]

I'm really not sure the rules of compatibility(match) between key exchange modes and the session tickets. For example, if the last flight was constructed via pure PSK, what shoud we set on ticket_flags (my understanding is it should be set to ALLOW_PSK_RESUMPTION) and how about other key exchange modes (i.g EPHEMERAL and PSK_EPHEMERAL)? Currently, I'm going to use the following configuration:

kex_mode        ticket_flags
------------------------------------
PSK             ALLOW_PSK_RESUMPTION
EPHEMERAL       ALLOW_PSK_EPHEMERAL_RESUMPTION
PSK_EPHEMERAL   ALLOW_PSK_EPHEMERAL_RESUMPTION

Other than that, I also want some inputs on the key exchange mode determination on server side. Currently, the server determines the key exchange mode regardless of the ticket_flags. For example, for a resumption connection, clienthello sent the ticket with ALLOW_PSK_RESUMPTION and key_exchange_modes_ext with psk_ke and psk_dhe_ke, should psk_ke be selected instead of psk_dhe_ke? Currently, psk_dhe_ke would be selected according to the built-in order of preference.

[yuhaoth]

I'm really not sure the rules of compatibility(match) between key exchange modes and the session tickets. For example, if the last flight was constructed via pure PSK, what shoud we set on ticket_flags (my understanding is it should be set to ALLOW_PSK_RESUMPTION) and how about other key exchange modes (i.g EPHEMERAL and PSK_EPHEMERAL)? Currently, I'm going to use the following configuration:

kex_mode        ticket_flags
------------------------------------
PSK             ALLOW_PSK_RESUMPTION
EPHEMERAL       ALLOW_PSK_EPHEMERAL_RESUMPTION
PSK_EPHEMERAL   ALLOW_PSK_EPHEMERAL_RESUMPTION

Firstly, it is impossible to do resumption with ephemeral. To keep the bit just for a quick kex mode check.
I think your question is about where the value is come from. For time being, directly copy it from handshake->tls13_kex_mode

   mbedtls_ssl_clear_ticket_flags( session, MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_ALL );
   mbedtls_ssl_set_ticket_flags( session, handshake->tls13_kex_mode );

ALLOW_*_RESUMPTION has been adjusted to align with MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE* and EPHERMAL is skipped.

Other than that, I also want some inputs on the key exchange mode determination on server side. Currently, the server determines the key exchange mode regardless of the ticket_flags. For example, for a resumption connection, clienthello sent the ticket with ALLOW_PSK_RESUMPTION and key_exchange_modes_ext with psk_ke and psk_dhe_ke, should psk_ke be selected instead of psk_dhe_ke? Currently, psk_dhe_ke would be selected according to the built-in order of preference.

I have post some comments in #6616. I think that can answer your question.

[ronald-cron-arm]

#6945 yet to be reviewed and merged

[yanrayw]

@lpy4105 May I ask is this one completed?

[lpy4105]

Since the PR related to this has got merged. I think this issue is completed. Feel free to close it.