RFC: Enabling the various key exchange methods under TLS1.3
TLS1.3 as its predecessor supports various key exchange methods such as pre-shared keys (with or without DH exchange), and DH exchange authenticated with public keys in certificates. On TLS1.2 the various key exchanges were selected based on the priority strings set on the application (NORMAL:+PSK:+ECDHE-PSK
, or NORMAL:-KX-ALL:+ECDHE-RSA
, etc). These strings resulted to the appropriate ciphersuites being prioritized, but as TLS1.3 doesn't encode the key exchange method in the ciphersuite, the priority strings become defunct.
Under TLS1.3 currently:
- The DH key exchange methods are set by the number of groups enabled in the priority string (e.g.,
+GROUP-FFDHE2048:+GROUP-SECP256R1
) - The number of speculative key shares sent by a client is configured using gnutls_init() flags
- The PSK key exchange methods are restricted to DH-based ones, and enabled when PSK credentials are set to the session
As such, we have a way to fine-tune or disable the session DH key exchange (by setting groups in 1) via the priority strings. The latter two are not configured via the priority strings. (2) can be argued to be a low-level detail, not to be exposed to the application user.
The third is something previously exposed to the application user (if it had access to config files, or otherwise option to priority strings), that is no longer accessible under TLS1.3. As long as the application sets PSK credentials, then PSK key exchange may happen.
The question is, should we treat that a regression and utilize the information in the priority strings (e.g., the +PSK
presence) in order to negotiate PSK, or simplify that part any only rely on the application writer?