Results are currently mixed: ask Google. More work needed on UDP flow-control versus state-of-the-art TCP, and it seems to suffer badly on some ISPs without any clear clue why (probably anti-P2P throttling, is my guess?).
Might end up influencing a future DTLS, but there's no roadmap that far ahead and the WG isn't chartered to discuss overhauls or big changes, according to the chairs: if we need a TLS 2.0, we're probably going to need a tls-ng Working Group with a more open-ended remit.
We're doing our best to get rid of the worst baggage from TLS 1.3: only forward-secure ciphersuites using AEADs (AES-GCM, ChaCha20-Poly1305 which is in CFRG consensus call now, etc), a... lively discussion about renegotiation, client authentication, key rollovers and plain DHE given the "triple handshake" vuln... a better PRF and handshake, maybe (Triple-DH?)? Still in progress. It's mostly going to be a big tidy-up I reckon, much like LibReSSL is for OpenSSL!
Curve25519 for ECDHE has a draft and is being discussed right now. I'm ready to implement and looking forward to it - big speed boost!
PKIX lags behind, however, and is one of the more dangerous parts to implement (ASN.1 and friends). Certificate handling is a real bitch to get perfect, and there's a lot of inertia: Ed25519 would be wonderful, but even ECDSA certs are rare as hen's teeth right now (not that I'm a fan of ECDSA as it's a nightmare to get right - see recent BoringSSL patches). A wholesale replacement is unfortunately way out of scope: too much baggage.
Might end up influencing a future DTLS, but there's no roadmap that far ahead and the WG isn't chartered to discuss overhauls or big changes, according to the chairs: if we need a TLS 2.0, we're probably going to need a tls-ng Working Group with a more open-ended remit.
We're doing our best to get rid of the worst baggage from TLS 1.3: only forward-secure ciphersuites using AEADs (AES-GCM, ChaCha20-Poly1305 which is in CFRG consensus call now, etc), a... lively discussion about renegotiation, client authentication, key rollovers and plain DHE given the "triple handshake" vuln... a better PRF and handshake, maybe (Triple-DH?)? Still in progress. It's mostly going to be a big tidy-up I reckon, much like LibReSSL is for OpenSSL!
Curve25519 for ECDHE has a draft and is being discussed right now. I'm ready to implement and looking forward to it - big speed boost!
PKIX lags behind, however, and is one of the more dangerous parts to implement (ASN.1 and friends). Certificate handling is a real bitch to get perfect, and there's a lot of inertia: Ed25519 would be wonderful, but even ECDSA certs are rare as hen's teeth right now (not that I'm a fan of ECDSA as it's a nightmare to get right - see recent BoringSSL patches). A wholesale replacement is unfortunately way out of scope: too much baggage.