One of my original goals from the very beginning of s2n was to move decisions like which protocols to support, which ciphers to prioritize and so on out of the

One of my original goals from the very beginning of s2n was to move decisions like which protocols to support, which ciphers to prioritize and so on out of the hands of system administrators and compliance auditors and into the hands of experts who go deep on the protocols and the trade-offs involved. I'd seen just far too many Apache and Nginx configs with non-sensical cipher configuration streams. On top of that goal we also layer the principal of making decisions that are driven by hard data, wherever possible, and not just fashions. We've changed the defaults in the past, in response to issues that we think are fatal blows, it's not about ossifying the default we happened to start with. It's simply that we know that right now if we disabled TLS1.0/1.1 by default; it would break some customers and users and we have a high bar to clear for that. At this point, only old clients who can do no better even negotiate TLS1.0/1.1. More modern clients can not be downgraded to TLS1.0/1.1 as long as they support the now well-deployed anti-fallback features that are in TLS. For those old clients that do use TLS1.0/1.1, the issues that are present in those protocol versions are not practically exploitable. The MD5_SHA1 handshake signature is probably the closest to exploitable and it is still not practical to compute those signatures within the handshake timeout windows. Other issues, like the lack of explicit IVs in 1.0 are mitigated with 1/n-1 record splitting (at least in one direction), and so on. Of course those old clients should upgrade and use TLS1.2! I just think there is a high bar for making them via brinkmanship, many of the clients left are things like BluRay players and TVs that shipped firmwares without an ability to do over the air updates. It'd just break things like video streaming and leave consumers figuring out how to flash-update an ancient device. I don't think it's good stewardship to force people through that. Now that some compliance requirements like FedRAMP/FIPS and PCI are starting to require TLS1.0/1.1 disabled, I do think we owe a simpler way to disable them for that reason. I do wish standards like that took a more deep and specific consideration of the risks involved. As for TLS1.3, we've been running and using it and contributed to its development and support for it is there, but we're still detecting clients that don't handle TLS1.3 correctly and have been working with them (and adding workarounds on our side). We have the benefit of a lot of data for all of these decisions, and we really want things to work reliably for people. Our customers tell us that's most important.