War against TLS 1.0

I have gotten into multiple discussions on the topic of TLS 1.0. The result always seems to end up in no change of anyone position. There are a few agreed to points:

SSL is fully forbidden.  TLS 1.2 is best TLS 1.0 and 1.1 are not as good as 1.2 Bad crypto algorithms must not be used (e.g. NULL, DES, MD5, etc)

However some people are taking a policy decision that TLS 1.2 is the ONLY protocol. They are allowed to make this policy change, as long as it doesn’t impact others that can’t support that policy I have no problem with a war on SSL. I simply have a realist view on available implementations of TLS 1.2 on platforms where software is available to run. I would love for everyone to have the latest protocols, and for those protocols to be perfectly implemented. Reality sucks! Standards Recommendation on TLS What is expressly frustrating is that they point at standards as their justification. YET those standards explicitly allow use of TLS 1.1 and TLS 1.0 in a very specific and important practical case… that is wen the higher protocol is not available. It is this last clause that seems to be escaping recognition. The ‘standard’ being pointed at is IETF (the writers of the TLS protocol) RFC7525.  This isn’t just an IETF specification, it is a “Best Current Practice” — aka BCP195 — May, 2015

Recommendations for Secure Use of Transport Layer Security (TLS)  and Datagram Transport Layer Security (DTLS) 

Let me excerpt the important part of that standard from section 3.1.1: Bold and highlight added for emphasis.  3.1.1 SSL/TLS Protocol Versions It is important both to stop using old, less secure versions of SSL/ TLS and to start using modern, more secure versions; therefore, the following are the recommendations concerning TLS/SSL protocol versions: o Implementations MUST NOT negotiate SSL version 2. Rationale: Today, SSLv2 is considered insecure [RFC6176]. o Implementations MUST NOT negotiate SSL version 3. Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and plugged some significant security holes but did not support strong cipher suites. SSLv3 does not support TLS extensions, some of which (e.g., renegotiation_info [RFC5746]) are security-critical. In addition, with the emergence of the POODLE attack [POODLE], SSLv3 is now widely recognized as fundamentally insecure. See [DEP-SSLv3] for further details.

o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation. Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors. o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]; the only exception is when no higher version is available in the negotiation. Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 but still does not support certain stronger cipher suites. o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2. This BCP applies to TLS 1.2 and also to earlier versions. It is not safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.

Note the last bullet tells you that you yourself must support TLS 1.2. A good thing if your platform allows it. Financial industry PCI standard Doesn’t PCI require that organizations stop using TLS 1.0? (Taken from Sequoia recommendation on TLS, as I a not a PCI expert)  As of 2016-11-23, the PCI issued the following text on their public web site at: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls which states “The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher). These dates provided by PCI SSC as of December 2015 supersede the original dates issued in both PCI Data Security Standard v3.1 (DSS 3.1) and in the //Migrating from SSL and early TLS// Information Supplement in April 2015.”

Conclusion Yes, it would be great if everyone had all the latest protocols, and that all those protocols were implemented without errors… BUT reality gets in our way. Especially so with Interoperability where reality is that we are trying to achieve Interoperability.  UPDATE: Reader should note that RFC7525 is very readable and full of far more recommendations than just TLS version. Including detailed discussion of cypher suites, and authentication types, etc. There is no perfect solution or configuration. Security is RISK MANAGEMENT, and needs continuous care and monitoring by an expert.