Specs designed by committee usually fail when they produce just the "paper" and no reference implementation. Look at W3C, which consistently failed to develop their own reference browser. The same seems true for TLS, actual implementations are too complicated because the committee paid no attention to this. A positive example is MP3, where everyone just copied the reference codec in the beginning.
Here's an interesting post about TLS compatibility[1]. I guess it explains why no browsers have had TLS 1.2 on by default for such a long time.<p>"
To add to this discussion about protocol version intolerance, I've been
tracking this problem in my SSL Pulse data set (SSL servers from the
Alexa top 1 million).<p>Here's what I have for November:<p><pre><code> Total servers: 163,587
TLS 1.0 intolerance 9
TLS 1.1 intolerance 1,388
TLS 1.2 intolerance 1,448 (~ 0.9%)
TLS 1.3 intolerance 17,840 (~10.9%)
TLS 2.98 intolerance 122,698 (~75.0%)
Long handshake intolerance: 4,795 (~2.9%)</code></pre>
"<p>1: <a href="https://www.ietf.org/mail-archive/web/tls/current/msg10657.html" rel="nofollow">https://www.ietf.org/mail-archive/web/tls/current/msg10657.h...</a>
Given recent revelations, one has to wonder if the working group merely failed by itself or was given a substantial nudge in that direction by someone who wanted TLS to be insecure.
Following the thread, the TLS 1.2 spec was completed in 2008, but it wasn't supported in OpenSSL until mid-2012 - so anything that depends on OpenSSL had to wait until at least then, then go through the implentation and reshipping, then trickle on down to the end vendors. And with no-one using TLS 1.2 or having a need for it because it wasn't available, it was back-burnered by the browsers.<p>The follow-up comments paint a much fuller picture of why things are delayed, where the failures are, and what's going on.
Maybe making things more intelligible would help instead of using language that is extremely obfuscated and confusing, and unaccompanied by any actual mathematics?<p>Take this sentence from the email for instance:<p>"Even AES-GCM got screwed up: nonces should be counters, but all implementations make them random, introducing an artificial birthday bound issue due to truncation in the standard."<p>I have no idea WTF this means, but let's go over it:<p>nonce: I know this is a randomly generated number that can be only used once -- now why should it be a counter? No idea.<p>"but all implementations make them random": wait, aren't they supposed to be random by definition? According to the above line though, they are supposed to be random. Damn, what I knew must be wrong. I wonder if this person on the internet has submitted some sort of explanation about this somewhere.<p>'artificial birthday bound issue': Assuming this refers to the birthday attack (<a href="http://en.wikipedia.org/wiki/Birthday_attack" rel="nofollow">http://en.wikipedia.org/wiki/Birthday_attack</a>). Why is it "artificial"? Can we see some mathematical proofs attached please? I sort of get the idea here -- because the nonce is random, it is vulnerable to being recreated after a certain number of attempts, but there is nothing concrete attached here. Or I could be totally wrong in this interpretation. God knows, and maybe this chap.<p>"...due to truncation in the standard." -- Do you mean some sort of <i>mathematical</i> truncation, i.e. "my number was truncated to 16 bits", or truncation of the standard itself "the last section of the standard was removed"? Please be clear.<p>Same goes for most things related to crypto -- if you want stuff like TLS to be examined by more eyeballs and find more bugs, you have to first try and make it more accessible. The sentences above are, in my opinion, a complete communication failure.