This article doesn't explain why they have so much trouble with versioning a protocol that is quite a lot simpler than many IP protocols that work. They shouldn't need GREASE, because anybody implementing TLS should be testing against a dedicated server, identified in the RFC, that connects as a client and jiggles all the knobs.
What, no conformance testing address is in the RFC? There's your problem right there.
To the conspiracy-minded among us, it is clear that "some people" don't want progress on encrypted communications, and know just what percentage of devices need to be intolerant of progress to stall adoption of fixes. Making browsers treat dropped connections as part of the protocol was very convenient for "those people". I.e., this is not (significantly) a matter of incompetent implementers, this is an enemy attack. Deployment plans that assume good faith by all parties fail under enemy attack.
As with everything cryptographic, a threat model is essential. Deployment is as much a part of the system and attack surface as the ciphers.
> What, no conformance testing address is in the RFC? There's your problem right there.
The vast majority of RFCs don't have conformance testing suites. IETF focuses on interoperability testing, which demonstrates that independent implementations work together for the major use cases, it doesn't test all the edge cases (such as future version negotiation) that a good conformance test would.
Creating and maintaining a conformance test is an order of magnitude more work than creating or maintaining a specification.
Someone has to be willing to expend the effort, and that usually means it has to make economic sense, and it rarely does.
And even when it does, in order to gain funding it often has to be licensed on commercial terms, which puts it out of reach of a lot of open source projects and smaller commercial implementors. (Even many large companies wouldn't pay for a test suite unless customers start putting it in RFPs.)
NIST used to maintain a whole bunch of free conformance test suites (CGM, COBOL, FORTRAN, PHIGS, POSIX, SQL), but the US government decided to stop paying for that.
The WHATWG and the W3C have been moving in a very different direction, treating testing as a major part of spec development, because the goal is to get implementations of the specifications, and how do you determine that if not by testing.
https://blog.whatwg.org/improving-interoperability is a post from the WHATWG side about this, and the outcome isn't just the direct "it's easier to write code against tests" but also "it's easier to notice when the spec changes" (because you now get a failing test).
Usually IETF WG members do testing and implementation (they run their modified version somewhere), but no information about that becomes part of the standard.
The protocol supports versioning just fine. There's an entire negotiation phase in the handshake just for that. The problem is there are too many broken implementations of TLS 1.2 out there.
What, no conformance testing address is in the RFC? There's your problem right there.
To the conspiracy-minded among us, it is clear that "some people" don't want progress on encrypted communications, and know just what percentage of devices need to be intolerant of progress to stall adoption of fixes. Making browsers treat dropped connections as part of the protocol was very convenient for "those people". I.e., this is not (significantly) a matter of incompetent implementers, this is an enemy attack. Deployment plans that assume good faith by all parties fail under enemy attack.
As with everything cryptographic, a threat model is essential. Deployment is as much a part of the system and attack surface as the ciphers.