What is the purpose of TLS cipher suites pairing? Why are they paired the way they are?

Question

Why are there predefined sets of cipher suites. Why is creating your own cipher suites not recommended.

Answer 1

We need more information about exactly what do you mean in your question, whether you're asking about TLS 1.3 or older versions, from SSLv3 up to TLS 1.2, which worked a little differently, and what kind of thing you would like to do that is currently impossible.

If you only intend to use primitives already specified for TLS and just want to mix and match them more freely, like SSH lets you do (KEX AUTH CIPHERS MAC), the answer for why you can't in TLS is probably partly historic and partly because fewer options means less complexity and more vetting of the allowed options.

It is more secure to have as few options as possible. Modern thinking is that cryptographic algorithm agility (an idea from the 1990s) was a mistake, and modern designs go as far as saying negotiation only causes trouble, and the correct thing to do is to only have a single negotiated value (protocol version) and to only support a single allowed value long term (you may need to support two possible values short term to allow upgrading clients and servers out of sync). So for example, with WireGuard, you get X25519 + ChaCha20Poly1305 + Blake2s. If any of the primitives turns out to be broken, or the joinery turns out to be broken, or something much faster is invented, or people decide to switch to something optimized for very different hardware, then the new protocol will be described with a new protocol identifier and people will switch, and there will not be a recommendation to maintain backwards compatibility for a long time.

So, if, for example, you want to do DHE 2048 + ECDSA P-256 + AES-128-GCM + SHA256 with TLS1.2, you can't, because there is no such cipher suite, although pretty standard client and server code could have supported this easily (IMO) and it would be secure to do (IMO). This is a restriction that I think buys little (improves combinatorics of test set).

What if you want to use your own primitive? For example, ECDH using Curve9767 instead of Curve25519 or NIST P-256? Or what if you want to use symmetric crypto based on Gimli or Xoodoo (also) instead of AESGCM or ChaPoly? Well, there are unassigned cipher suite ids you can use. You can implement a server that chooses your cipher suite if the client offers it, and implement a client that offers it and uses it if it is chosen by the server, and if the connection is made between a supporting client and server then the new cipher suite is used. This is how Google, Cloudflare and AWS did their post quantum cryptography experiments and how some people used national vanity ciphers (🇷🇺 🇨🇳).

What if you want to change the PRF, so your client won't need to have a SHA2 implementation (suppose you use Blake3 in the signature and as MAC or something)? A ciphersuite can do that (IIRC).

What if you want to change the joinery, the way the primitives are combined?

For example, instead of using asymmetric signatures, you want to use ECDH+HMAC for asymmetric authentication, like Noise does. That might be a new value of SignatureAndHashAlgorithm that changes the flow (if offered by client and chosen by the server). Or maybe an extension. I'm not sure.

Basically, the idea is that ClientHello message looks the way the RFC says, but unknown cipher suites are allowed and new extensions are allowed, and an extension can change the protocol completely. Compliant middleboxes should not even expect the ServerHello, Certificate and ServeKeyExchange messages to be present and make sense, because an extension in ClientHello could mean "let's switch to a completely different protocol" to a server that supports it. Unfortunately, in practice, middleboxes are the bane of everyone's existence and TLS1.3 had to do some cosmetically weird things to work, and major alteration to TLS1.2 flow using extensions would probably not work for clients behind corporate middleboxes. But in your internal network it would be fine. TLS1.3 encrypts more of the handshake to hide what it does from middleboxes (and for privacy), so extending it is easier.

What if you want to use something other than X.509 certificates for asymmetric authentication? TLS spec says you must use X.509. If you change the protocol enough, it's time to stop calling your creation "TLS". This is what Google have done with what they use internally.