Non-obsolete crypto is relatively easy to achieve with Chrome and Firefox, but not as much with IE and Safari, and many other clients.
There's no doubt that sites with authenticated crypto should get a better score, but it's not straightforward to establish fair criteria. For example, should SSL Labs penalise sites that don't use authenticated encryption with IE? Because, to do that, you must either accept the DHE key exchange or deploy with dual (RSA and ECDSA) keys. The former is slow, while the latter requires more effort.
You could say that SSL Labs should focus only on the cases where it is possible to use authenticated encryption, but that creates another problem: should SSL Labs report the reality, or award best effort? It's not easy to decide, but so far I've been leaning toward the reality.
Finally, there's the case of using ChaCha20/Poly1305; should SSL Labs encourage the use of cipher suites that are not yet standardised? Should Google get a pass because we "know" they know what they're doing?
And yes: you should be encouraging Salsa/Poly1305. They're de facto standards, and will very soon be de jure standards as well. Plenty of other "nonstandard" behavior is encoded into TLS. It's also not fair to call Salsa/Poly1305 a "Google" initiative.
Making the effective top grade a B might also reduce the physiological motivation for improving a seriously bad TLS config. At least in the US, anything less than an A is considered very close to failing these days (it's silly, but it's the reality). Making changes just to get a B isn't nearly as motivational as making changes to get an A.
And to be clear, I'm not saying we shouldn't be moving away from the CBC ciphers as fast as possible - just that dishing out a B grade for supporting a large number of users is not a good way of accomplishing that.
* Grade 'A' requires AES-GCM and ChaCha20Poly1305
* Allow CBC for 'A' iff it's a last resort option
* Use nginx equivalent of "ssl_prefer_server_ciphers on;"
CBC would then only be used by clients that don't support AE ciphersuites.
I think not negotiating GCM on a browser where GCM is available and not using it will produce a warning should cap the mark at a B.
Understood re: IE.
Agreed re: ChaCha20/Poly1305, at least until openssl ships it (and maybe longer).
> Finally, there's the case of using ChaCha20/Poly1305; should SSL Labs encourage the use of cipher suites that are not yet standardised?
Ie, I don't think it's worth encouraging CHACHA20/POLY1305 until people can use it.
We need to get away from the idea that it's unfair to recognize superior cryptography merely because it's currently only implemented in Chrome.
The grade either reflects the actual quality of a server's TLS configuration, or it reflects something else.
In any case, it's a moot point here, because ChaCha20/Poly1305 is RFC7593.
Accepting non-standard crypto is a slippery slope, which is why I'd rather take a very conservative approach.
P.S. You mean RFC 7539, which came out only a couple of days ago. Now we only need another RFC for the use in TLS.
That doesn't change that people won't use it until it's in openssl properly and they don't have to maintain a patched version themselves.
There are two options: enable the only modern native stream cipher available for TLS, and with it the only polynomial MAC that doesn't require hardware support (and thus the best polynomial MAC available for mobile devices), or don't.
The former option is superior to the latter option. The latter option is easier, but: nobody said engineering was supposed to be easy.
Either SSL Labs is evaluating the quality of TLS implementations, or they're evaluating something else. Arguments like the ones I see on this thread suggest it's "something else".