Openssl: Revisit and modernize ciphersuite specification mechanism ("cipher string")

[kaduk]

There is pent-up demand for a more flexible solution than the current cipherstring setup, most notably for equal-preference grouping (#541) and a more general solution than SSL_OP_PRIORITIZE_CHACHA (#4436).

Rather than focusing on a specific mechanism ("bracketed equal-preference" or "prioritize chacha"), let's try to step back and think about what is actually needed (including whether @STRENGTH still makes sense, since that is not easily compatible with the bracketed equal-preference scheme) and how we can fill that need.

However, this is likely to be a big revamp and might be backwards incompatible, so let's mark this as for 1.2.0/post-1.1.1 to start.

[blblack]

SSL_OP_PRIORITIZE_CHACHA and various ForMobile sorts of thinking are short-term and myopic takes on all related things at best. Why are we now pushing off to design discussion headed for 1.2.0 when the core issues here were brought up 2 years ago in #541 and neglected?

As this ticket rightly notes, it's not about a specific implementation. It's about expressing the logical capabilities that are desirable from the server administrator's point of view. Those capabilities happen to map well to the equal-preference grouping proposal, which is probably why that solution was chosen elsewhere as well. It's ok to come up with a better design that still captures all the desirable properties, but I think it's a shame to reject it without proposing a superior alternative in all this time.

What's logically desirable to the server administrator is the ability to express a policy that server preference comes first, but that within certain sub-lists, the client's preferences should be honored. In other words, the ability to say things like: "I'm enforcing a server policy preference that [AB] is preferable to [CD] is preferable to E, but I'd rather leave it up to client policy choices which specific cipher to use within either bracketed set". This is already desirable in TLSv1.2, most-notably due to the ChaPoly preference issues. It will also be desirable in TLSv1.3 for all the same reasons plus unknown future ones.

I feel like a broken record here, but I'll re-iterate again:

1) TLSv1.3 won't always have just the 3 cipher choices it has today.
2) TLSv1.3's ciphers won't always have the property that they're all widely considered very loosely equal in pragmatic strength by many.
3) Some administrators don't view any of the current 3 choices to be equivalent, either, and some of that thinking depends on your organization's policy stances about different forms of risk.
4) Server-side performance problems are easier to solve that client-side ones, and the current and future cipher choices definitely differ in client-side performance impact, which is also going to impact server policy in a way that requires looking at the client's preferences.
5) Leaving this whole issue up to being a code hook for applications that link OpenSSL, with the library-native capabilities being insufficient, is a bad idea for the ecosystem. Many many more applications link OpenSSL for TLS support than was the case in the past. Most of their authors are struggling just to get the basics done right and don't expose enough configuration to the administrators as it is. The major traditional webservers are all going to implement the mapping of those code hooks to administrator configuration in divergent ways, and the slew of new TLS codebases will probably ignore it and/or implement it poorly, leaving the administrators to go file bugs about each and every one of them.

[blblack]

I should add, if we're broadening the discussion anyways, that for TLSv1.3 these same issues also potentially exist for the bits that are no longer part of the "cipher" - e.g. the choice of ecdhe curves, etc.

[beren12]

I notice that my debian boxes all go to chacha if it's available, this slows down my older servers by 2-3x since they have aes-ni. It seems openssl went a little aggressive preferring chacha.