Select TLS config and setup details

TLS config details should be specified and implementation updates propagated to the appropriate repositories. We do not want to use the default configuration for TLS, which provides for a way for the end points to negotiate a ciphersuite protocol.

Instead, we should select an appropriately strong ciphersuite and mandate a minimum version of TLS 1.3. We also need a plan for incremental updates, i.e. we should ensure that

We never require a Flag Day (a single time when everyone has to upgrade at the same time).
We prevent rollback attacks: if TLS 2.0 or a new ciphersuite comes out because someone find a security flaw in the old one, an adversary should not be able to trick Alice and Bob (who each support the new better one) to nonetheless negotiate the old one.

The TLS dependency details are tucked away in the transport crate. We use the rustls crate for the baseline protocol and the tokio_rustls crate to make it asynchronous.

Should I look for more configuration details here? A quick look suggests that we use the library defaults for configuring our server, which are described by rusttls here:

If used, this will enable all safe supported cipher suites (DEFAULT_CIPHER_SUITES), all safe supported key exchange groups (ALL_KX_GROUPS) and all safe supported protocol versions (DEFAULT_VERSIONS).

These are safe defaults, useful for 99% of applications.

_Originally posted by @marsella in https://github.com/boltlabs-inc/key-mgmt-spec/pull/20#discussion_r920098067_

We should also decide on our use of PKI and PSKs for session resumption. Some considerations:

Need to be very careful in how you handle certificate signing. We can use a custom certificate issuer and use 2-way certs where possible (e.g., the remote client in key-mgmt).
The implementation must trust only the custom cert issuer.
For deployment, we must have a plan to handle handle the issuer key with extreme care.

boltlabs-inc / key-mgmt-spec

Select TLS config and setup details #22