Well, my only real point is that it’s not the version negotiation in TLS that’s broken. It’s the workaround for intolerance of newer versions that had downgrade attacks.

Fortunately that’s all behind us now, and transitioning from 1.2 to 1.3 is going much smoother than 1.0 to 1.2 went.

One of the big differences was in attitude. The TLS 1.3 anti-downgrade feature was not compatible with some popular middlebox products. Google told people too bad, either your vendor fixes it (most shipped free bug fixes for this issue, presumably "encouraged" by the resulting customer anger) or you can't run Chrome once this temporary fudge goes away in a year's time.

Previously (in earlier protocol versions) nobody stood up to the crap middleboxes even though it's bad for all normal users.

The service providers were the worst offenders here because they wanted to be the MIM to be able to look at the data and “add value” to their networks some how. Moving to TLS 1.3 took a lot of that away from them and it was only Google’s market power that could break them.

Similar thing has been happening with email sender auth, with Gmail and other big providers enforcing things

Any chance that can be used to undo lots of the ossification that made QUIC a UDP based hack rather than it's own level 4 protocol?

It's probably too hard to get NATs to agree on a new L4 protocol.

Basically none.

First the success rate of any new IP-based protocol through most devices is incredibly low, especially now that NAT is so common.

Second, part of why QUIC runs over UDP is because the operating system generally won't let applications send raw IP datagrams.

Even running over UDP, QUIC has nontrivial failure rates and the browsers have to fall back to TLS over TCP.

> I always bring it up as a good example to contrast with XMPP as a bad example.

Could you expand a bit here? Do you just mean how extensions to the protocol are handled, etc., or the overall process and involved parties?

XMPP is too loose. Easiest comparison is security alone. XMPP auth and encryption are complicated, and they're optional for each of c2s, s2c, s2s (setting aside e2e). Clients and servers will quietly do the wrong thing if not configured exactly right. Email has similar problems, so bad that entire companies exist just to help set up stuff like DMARC, but that's a simpler app than instant messaging. The rest of the XMPP feature set is also super loose. Clients and servers never agree on what extensions to implement, even for very basic things like chat rooms. I really tried to like it before giving up.

Edit: https://wiki.xmpp.org/web/Securing_XMPP

SSL is appropriately strict. Auth and encryption, both c2s and s2c, go together. They were a bit lax on upgrades in the past, but as another comment said, Google just said you fix your stuff or else Chrome will show a very scary banner on your website. Yes you can skip it or force special things like auth without encryption, but it's impossible to do by accident.

thanks for taking the time to respond!