The changelog says:
*) State machine rewrite. The state machine code has been significantly
refactored in order to remove much duplication of code and solve issues
with the old code (see ssl/statem/README for further details). This change
does have some associated API changes. Notably the SSL_state() function
has been removed and replaced by SSL_get_state which now returns an
"OSSL_HANDSHAKE_STATE" instead of an int. SSL_set_state() has been removed
altogether. The previous handshake states defined in ssl.h and ssl3.h have
also been removed.
[Matt Caswell](I think there is also another group in the UK that works on this problem and also got important results.)
Weak DH and ECDHE using NIST curves concerns me far more than AES-GCM which is readily available for example. Configuring DH properly requires extra effort for administrators and ECDHE relies on NIST curves which are prone to implementation error and some have even called into question the NSA-NIST relationship behind the "random" curves.
The NIST P- curves in TLS ECDHE have sound implementations in Chromium and Firefox. Nobody should be using conventional DH in preference to ECDHE; if you can't trust a browser's P-curves, you can't trust their GCM either.
Is that true though? I mean, from what I've read GCM seems much easier to implement than a full ECDH. I mean, have a look at some of the things published by Bernstein and Lange, https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
They do certainly have a horse in the race, but it's still interesting. They and others have also raised concerns about potential backdoors in the NIST curves, which is, while still unproven another reason why one might avoid them. They failed to do things as basic in the cryptographic community as using "nothing up my sleeve" numbers, it just seems sketchy at best to me. The random curves at least. The others are probably still just fine but the random ones are the most popular in TLS.
Better ECDHE is ready to be rolled out though: https://tools.ietf.org/html/draft-irtf-cfrg-curves-11
Too bad how long CFRG take to get EdDSA ready.
That's not true. For an example, see Schneier's comment here:
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...
Or Bernstein and Lange's comments here:
https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
(specifically the: Jerry Solinas at NSA used this to generate the NIST curves (or so he says))
I believe Matthew Green may have also made a similar statement, though I can't find it, so perhaps I'm not recalling correctly. In any case, I don't think you can outright say "No cryptographers believe the NIST curves are backdoored". You can at best say "No cryptographers have proven the NIST curves are backdoored", which is true.
However, those cryptographers have also raised concerns (including concerns about backdoors) and I just hope we move to safer alternatives quicker.
https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-pol...
http://www.iana.org/assignments/tls-parameters/tls-parameter...
In the mean time, the I-D does contain the requested values in section 3:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAA}
TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAB}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAD}
TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAE}
I say that as someone who is resident on ##openssl and have seen many people try and run into issues.
Edit: https://openssl.org/news/newslog.html says "Alpha 1 of OpenSSL 1.1.0 is now available"
There are some additional details required to use the cipher for TLS. In particular the new modes must be assigned entries in the TLS Cipher Suite Registry, which contain the official names and the numeric values used in the wire protocol. The current draft also specifies how to construct the nonce from the record sequence number and a shared secret, to avoid having to send a nonce with each record.
ECDH itself is very easy to implement; it's just DH (which is probably the simplest algorithm in cryptography), but in a different group.
ECC (the group) is hard to implement safely. The NIST P-curves are tricky to implement relative to Curve25519.
But there's also a lot more study of how to safely implement the NIST P- curves than there is for how to make a constant-time GCM.
I don't know. They seem like comparably difficult tasks.
It's worth keeping in mind that Schneier is also not an academic cryptographer, or really a serious practicing cryptography researcher of any sort. He's a great popularizer and he works with some very credible other researchers, but "Schneier said so" is never going to win a debate among cryptographers.
Bernstein makes the same kinds of comments about the Brainpool curves (the whole point of BADA55 was that the Brainpool curves aren't that much more trustworthy than the Solinas curves), and nobody, including Bernstein, will with a straight face say that the Brainpool curves are backdoored.
It's a valid process critique that has been interpreted by laypeople as an accusation, which is something Bernstein has taken flak for.