m-ronnblom
commented
9 months ago Preferably, the XCM socket attributes structure used should naturally extend to support a future XCM version also supporting older, pre-1.2 versions of TLS, and newer, post-1.3, versions.
Allow the application to control which TLS versions and cipher suites are used for a particular socket.
TLS version and cipher configuration should be available in all TLS-based XCM transports (TLS, UTLS, BTLS).
TLS version and cipher configuration should be inherited from a server socket to corresponding connection sockets (created with xcm_accept() or xcm_accept_a()).
TLS version configuration
The application may not choose arbitrary SSL or TLS versions; only 1.2 and 1.3 will be available. Enabling/disabling of a TLS protocol version must be done explicitly, with a separate socket attribute. This seems preferable over implicit configuration, by means of just leaving out all TLS 1.2 cipher in case TLS 1.2 are to be disabled. Explicit is better since it's more clear, although arguably a little redundant.
By default, both TLS 1.2 and 1.3 will be enabled (to assure backward compatibility).
Only TLS 1.2 and 1.3, and not any older TLS or SSL protocol version will be supported by XCM. The socket attribute design should allow future XCM version allowing enabling of older TLS or SSL protocol versions or newer, yet-to-be-specified versions of TLS.
TLS cipher configuration
The default TLS 1.3 and 1.3 ciphers currently hard-wired into the XCM TLS transport should continue to be the default.
The application should be able to override the default ciphers for either/both-of TLS 1.2 and 1.3 by means of XCM socket attributes.
The should probably be two separate lists, one for TLS 1.2 and one for TLS 1.3, although technically, you could potentially have one list, given that cipher names seems to be unique. At this point, the "two list" solution seems more clear and not subject to any issues, does not depend on unique crypto suite names. The "two list" solutions also avoid having to explain to the user what happens if the cipher list contains TLS 1.2-only ciphers, but TLS 1.2 is disabled.
Cipher suite names used in the XCM API should be the IANA names (i.e., not IANA hexcodes, and not OpenSSL names).
It's unclear if XCM should only support the ciphers currently hard-coded into the library (i.e., the default will be a superset of all available cipher lists), or if all OpenSSL-supported cipher suites should be available for the application to enable (incuding NUL-crypto), or there should be something in-between.
The should probably be a way for an application to retrieve both the default cipher list, and more importantly, the list of available ciphers (for all supported TLS versions). This information cannot be conveyed as a socket attribute, since it's not related to a socket, but rather a transport, so there would have to be new API calls.
Handshake Result
There should be a way to retrieve both actual ciphers used for a particular connection, and the protocol version (that is already logged today, but not available programmatically), as socket attribute readable after the TLS handshake has completed.