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

  • 1
    See tlseminar.github.io/first-few-milliseconds, and scroll down to 'Part 1 - Client Hello', where the server sends the client the list of cipher suites that it supports. If the server didn't send this list, then how would the client know which combinations the server supports? If the client or the server were to just 'create their own cipher suite' on the fly, there would be a high likelihood that the other wouldn't support it. That's why one (the server) needs to advertise to the other (the client) which suites it supports.
    – mti2935
    Mar 26 '20 at 15:44
  • The client needs to be able to use the cipher ...
    – schroeder
    Mar 26 '20 at 15:49
  • 1
    "why do I need to use an established language when I go shopping? why can't I invent my own language?" -- because the people you are talking to need to know the language too
    – schroeder
    Mar 26 '20 at 15:50
  • 2
    @mti2935: "... where the server sends the client the list of cipher suites that it supports ... That's why one (the server) needs to advertise to the other (the client) which suites it supports." - it is the other way around. The client send the server the list of supported ciphers (and the server picks one which it supports too). Mar 26 '20 at 17:12
  • 1
    In a system that connects between clients and servers under your full control, you can use custom cipher suites (for example, to use national vanity ciphers like SM and GOST) which you define yourself and are not present in the RFCs and IANAs lists. You can even modify the protocol itself, for example not use x509 and use protobuf instead, but then it's a good idea to not call it TLS (google do this, it's called ATLS) because you changed a significant part. There is no police to arrest you for not being compliant with RFCs. To talk to e.g. amazon.com's server, use what it can understand.
    – Z.T.
    Mar 26 '20 at 17:40

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.

  • Minor nitpick: China's two-letter abbreviation is CN. CH stands for Confoederatio Helvetica, more commonly known as Switzerland.
    – MechMK1
    Mar 27 '20 at 12:20
  • @MechMK1 fixed, thanks.
    – Z.T.
    Mar 27 '20 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.