TLS Traits

e.g. for rustls-rustcrypto whilst validating OpenSSL interop

These traits could be not only useful for validation, testing and benchmark purposes and perhaps modelling TLS regardless the implementation where the underlying implementation can be switched behind.

There is already significant work trying to bridge between rustls / OpenSSL and making them universally switchable impls.

One common theme on TLS traits debate would probably be either lack of or embrace of async function coloring for I/O side.

Another debate probably is around how and how much API should protect mis-use and how to model the dangerous use of API

Think it should be sans-io and I/O layer is not in the scope for these traits - and should not involve OS/env decisions.

One thing rustls has adopted is typestate pattern in config builders to protect against misuse which could be helpful to model

Pondering along the lines of rand_core type traits like RngCore + CryptoRng == CryptoRngCore model for config:
e.g. TlsConfigCore + [ TlsClientConfig | TlsServerConfig ] == Tls[Client|Server]ConfigCore traits

These "config core" traits could cast finalized to Tls implementation e.g. Client / Server specific probably that has re-negotiation / resumption etc. stuff but config is probably the initial low hanging fruit to address at shared trait level.

Start by reviewing the rand_core trait model and the cited rustls-rustcrypto work, then compare how rustls and OpenSSL are currently bridged. The issue does not define a settled trait surface or acceptance criteria, so the work would first require agreeing on the sans-IO scope, async approach, misuse protections, and configuration model.