TLS 1.2 Long-term Support Profile

The TLS-LTS profile specifies a few simple restrictions on the huge range of TLS suites, options and parameters to limit the protocol to a known-good subset, as well as making minor corrections to limit various attacks.

TLS-LTS restricts the more or less unlimited TLS 1.2 with its more than three hundred cipher suites, over forty ECC parameter sets, and zoo of supplementary algorithms, parameters, and parameter formats, to just two, one traditional one with DHE + AES-CBC + HMAC-SHA-256 + RSA-SHA-256/PSK and one ECC one with ECDHE-P256 + AES-GCM + HMAC-SHA-256 + ECDSA-P256-SHA-256/PSK with uncompressed points: TLS-LTS implementations MUST support TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256.

TLS-LTS only permits encrypt-then-MAC, not MAC-then-encrypt, fixing 20 years of attacks on this mechanism: TLS-LTS implementations MUST implement encrypt-then-MAC rather than the earlier MAC-then-encrypt. TLS-LTS drops the IPsec cargo-cult MAC truncation, which serves no obvious purpose and leads to security concerns: TLS-LTS implementations MUST use full-length MAC values (for example 256 bits for SHA-256). In particular MAC values MUST NOT be truncated to 96 bits/12 bytes, removing the verify_data_length constraint in the Finished message. TLS-LTS recommends that implementations take measures to protect against side-channel attacks: Implementations SHOULD take steps to protect against timing attacks, for example by using constant-time implementations of algorithms and by using blinding for non-randomised algorithms like RSA. Implementations SHOULD take steps to protect against fault attacks, in particular for the extremely brittle ECC algorithms whose typical failure mode if a fault occurs is to leak the private key. One simple countermeasure is to use the public key to verify any signatures generated before they are sent over the wire. TLS-LTS signs a hash of the client and server hello messages for the ServerKeyExchange rather than signing just the client and server nonces, avoiding various attacks that built on the fact that previously-exchanged parameters weren't authenticated at that point: When generating the ServerKeyExchange signature, the signed_params value is updated to replace the client_random and server_random with a hash of the full ClientHello and ServerHello. In other words the value being signed becomes:

The choice of key sizes is something that will never get any consensus because there are so many completely different worldviews involved. TLS-LTS makes only general recommendations on best practices and leaves the choice of which key sizes are appropriate to implementers: Implementations SHOULD choose public-key algorithm key sizes that are appropriate for the situation, weighted by the value of the information being protected, the probability of attack and capabilities of the attacker(s), and the ability of the system running the TLS implementation to deal with the computational load of large keys. For example a SCADA system being used to switch a ventilator on and off doesn't require anywhere near the keysize-based security of a system used to transfer classified data. One way to avoid having to use very large public keys is to switch keys periodically. This can be done by regenerating DH parameters in a background thread and rolling them over from time to time. If this isn't possible, an alternative is to pre-generate a selection of DH parameters and choose one set at random for each new handshake, or again rolling them over from time to time, so that an attacker has to attack n sets of parameters rather than just one.

TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style, not p and g only, PKCS #3 style. This allows verification of the DH parameters, which the current format doesn't allow: TLS-LTS implementations MUST send the DH domain parameters as { p, g, q } rather than { p, g }. This makes the ServerDHParams field:

; opaque dh_g<1..2^16-1>; opaque dh_q<1..2^16-1>; opaque dh_Ys<1..2^16-1>; } ServerDHParams; /* Ephemeral DH parameters */ ]]> The domain parameters MUST be verified as specified in FIPS 186. TLS-LTS adds a hash of all messages leading up to the calculation of the master secret into the master secret to protect against the use of manipulated handshake parameters: TLS-LTS implementations MUST implement extended master secret to protect handshake and crypto parameters.

TLS-LTS drops the need to send the current time in the random data, which serves no obvious purpose and leaks the client/server's time to attackers: TLS-LTS implementations SHOULD NOT include the time in the Client/ServerHello random data. The data SHOULD consists entirely of random bytes. TLS-LTS drops compression and rehandshake, which have led to a number of attacks: TLS-LTS implementations MUST NOT implement compression or rehandshake.

TLS-LTS requires that RSA signature verification be done as encode-then-compare, which fixes all known padding-manipulation issues: TLS-LTS implementations MUST verify RSA signatures by using encode-then-compare as described in PKCS #1, meaning that they encode the expected signature result and perform a constant-time compare against the recovered signature data. The constant-time compare isn't strictly necessary for security in this case, but it's generally good hygiene and is explicitly required when comparing secret data values: All operations on crypto- or security-related values SHOULD be performed in a manner that's as timing-independent as possible. For example compares of MAC values such as those used in the Finished message and data packets SHOULD be performed using a constant-time memcmp() or equivalent so as not to leak timing data to an attacker. The TLS protocol has historically and somewhat arbitrarily been described as a state machine, which has led to a number of implementation flaws when state transitions weren't very carefully considered and enforced. A more logical means of representing the protocol is as a ladder diagram, which hardcodes the transitions into the diagram and removes the need to juggle a large amount of state: Implementations SHOULD consider representing/implementing the protocol as a ladder diagram rather than a state machine, since the state-diagram form has led to a number of implementation errors in the past which are avoided through the use of the ladder diagram form. TLS-LTS protects its handshake by including cryptographic integrity checks of preceding messages in subsequent messages, defeating attacks that build on the ability to manipulate handshake messages to compromise security. What's authenticated at various stages is a log of preceding messages in the exchange. The simplest way to implement this, if the underlying API supports it, is to keep a running hash of all messages (which will be required for the final Finished computation) and peel off a copy of the current hash state to generate the hash value required at various stages during the handshake. If only the traditional { Begin, [ Update, Update, ... ], Final } hash API interface is available then several parallel chains of hashing will need to be run in order to terminate the hashing at different points during the handshake.

TLS-LTS is inspired by Grigg's Law that "there is only one mode and that is secure". Because it mandates the use of known-good mechanisms, much of the signalling and negotiation that's required in standard TLS to reach the same state becomes redundant. In particular, TLS-LTS removes the need to use the following extensions: The signature_algorithms extension, since the use of SHA-256 with RSA or ECDSA is implicit in TLS-LTS. The elliptic_curves and ec_point_formats extensions, since the use of P256 with uncompressed points is implicit in TLS-LTS. The almost universally-ignored requirement that all certificates provided by the server must be signed by the algorithm(s) specified in the signature_algorithms extension is removed both implicitly by not sending the extension and explicitly by removing this requirement. The encrypt_then_mac extension, since the use of encrypt-then-MAC is implicit in TLS-LTS. The extended_master_secret extension, since the use of extended Master Secret is implicit in TLS-LTS. TLS-LTS implementations that wish to communicate only with other TLS-LTS implementations MAY omit these extensions. Implementations that wish to communicate with legacy implementations and wish to use the capabilities described by the extensions MUST include these extensions.

The use of the TLS-LTS improvements relies on an attacker not being able to delete the TLS-LTS extension from the handshake messages. This is achieved through the SCSV signalling mechanism. [SCSV boilerplate to be filled in later, this will also require banning weak cipher suites like export ones. This is a tautology, will have to work out how to ban something that in theory has already been extinct for 15 years].

A question that may be asked at this point is, why not use TLS 1.3 instead of creating a secure profile of TLS 1.2? The reason is that TLS 1.3 rolls back the 20 years of experience that we have with all the things that can go wrong in TLS and starts again from scratch with an almost entirely new protocol based on bleeding-edge/experimental ideas, mechanisms, and algorithms. When SSLv3 was introduced, it used ideas that were 10-20 years old (DH, RSA, DES, and so on were all long-established algorithms, only SHA-1 was relatively new). These were mature algorithms with large amounts of of research published on them, and yet we're still fixing issues with them 20 years later (the DH algorithm was published in 1976, SSLv3 dates from 1996, and the latest DH issue, Logjam, dates from 2015. With TLS 1.3 we currently have zero implementation and deployment experience, which means that we're likely to have another 10-20 years of patching holes and fixing protocol and implementation problems ahead of us. It's for this reason that this profile uses the decades of experience we have with SSL and TLS to simplify TLS 1.2 into a known-good subset that leverages about 15 years of analysis and 20 years of implementation experience, rather than betting on what's almost an entirely new protocol based on bleeding-edge/experimental ideas, mechanisms, and algorithms. The intent is to create a long-term stable protocol profile that can be deployed once, not deployed and then patched, updated, and fixed constantly for the lifetime of the equipment that it's used with.