Select TLS config and setup details

[indomitableSwan]

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 #20 (comment)

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.

[LordQ1]

Swan says that we do need this ticket, but we do not need it for the Passive Keys release. Removing it from the release.