I know this timeline prefers primary sources and tries to avoid blog posts, but Cloudflare's blog post 'Staying on top of TLS attacks' [1] dated July 11, 2013, was a milestone.
It came in the wake of 'Lucky 13' and the demonstration of RC4 biases exploitable in TLS, and showed the awkward situation that existed at the time: essentially all supported ciphersuites were vulnerable to something, and no mainstream browser supported TLSv1.2 yet in which non-vulnerable ciphersuites were present.
Even if a reference isn't made to the blog post, the timeline should somehow reference the aforementioned ciphersuite conundrum.
I don't think this blog post broke that news: it pretty much follows directly from Lucky 13 and RC4, both of which are documented in the timeline. It would be pretty weird to add a blog post about two other things in the timeline to the timeline itself.
I suppose you're right. The timeline avoids editorializing but at the same time tries to inform, and in my opinion it would be valuable to inform that from March 2013 until Chrome shipped TLSv1.2 in August 2013, there was no good cipher to pick that didn't have an exploit.
As it stands now you have to combine different pieces of information, some already included in the timeline (RC4, Lucky 13, Chrome TLSv1.2), some you have to know by knowing what's in TLSv1.1 and what's not (yet) in it.
I also don't think it's a great idea to open up the can of worms about whether "no viable TLS ciphersuites" began with Lucky 13 or with RC4 (which depends on whether you think the most recent RC4 paper was the death knell for RC4, or whether the Fluhrer-McGrew biases were).
Please add the changes that resulted from Brian Smith's (of Mozilla) blog post 'Proposal to Change the Default TLS Ciphersuites Offered by Browsers' [1] -- the post dates to August 2013.
This was a very impactful proposal that changed the way browsers preferred ciphersuites. But it also removed some lesser-used ciphersuites based off of telemetry [2], including the block cipher Camellia, which was the only other modern block cipher in TLS after AES.
Note: I can’t claim to write anything even close to this timeline about PKI!
Many of these items seem correct to include in "A comprehensive history of the most important events that shaped the SSL/TLS and PKI ecosystem”, however it feels very… inconsistent in inclusion.
Dates are given when browser implement protocol support, but not OpenSSL, NSS, etc. (Actually, nothing positive is said about OpenSSL at all.) Also no mention of Nginx, Apache or IIS and their TLS/SPDY support/features?
Brian Smith is mentioned by name working on a Rust crypto library, but no mention of DJB when discussing ChaCha20-Poly1305? (Is Ring actually used by any major projects so far?)
I suppose it's a question of balance; I am trying to include all that's relevant while at the same time keeping the list reasonably small. If I add too many items, the main ones will be lost in the noise. (I have an idea of how I could manage this, but including categories and filters in the future.)
Perhaps the inclusion of ring is a tad premature, but that's because I have very high hopes for this project. Brian is the only one taking a long-term view and doing what we're all supposed to be doing -- minimising the amount of C code we depend upon.
> (Is Ring actually used by any major projects so far?)
So, we're at the beta stage of releasing https://rustup.rs/, which is going to be the official way to download Rust in the future. It uses rusttls, which uses ring.
You tested Netscape Navigator 2.01 and SSLv3 isn't supported in it? I'll check myself; in the meantime, I removed that sentence from the timeline. Thanks!
It came in the wake of 'Lucky 13' and the demonstration of RC4 biases exploitable in TLS, and showed the awkward situation that existed at the time: essentially all supported ciphersuites were vulnerable to something, and no mainstream browser supported TLSv1.2 yet in which non-vulnerable ciphersuites were present.
Even if a reference isn't made to the blog post, the timeline should somehow reference the aforementioned ciphersuite conundrum.
[1] https://blog.cloudflare.com/staying-on-top-of-tls-attacks/