TLS 1.2 Update for Long-term Support

3.1. Encryption/Authentication

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_GCM_SHA256. For these suites, SHA-256 is used in all locations in the protocol where a hash function is required, specifically in the PRF and per-packet MAC calculations (as indicated by the _SHA256 in the suite) and also in the client and server signatures in the CertificateVerify and ServerKeyExchange messages.¶

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 [EtM] rather than the earlier MAC-then-encrypt.¶

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 [EMS] to protect handshake and crypto parameters.¶

In several locations TLS modifies or truncates the output of cryptographic operations so that the original security guarantees associated with them may no longer be valid. TLS-LTS utilises the full cryptographic parameters rather than partial, truncated, or otherwise modified forms. In particular, TLS-LTS drops the MAC truncation of the Finished message contents and uses the full elliptic curve point Q output from the ECDH key agreement mechanism rather than the point's x coordinate by itself:¶

• The length of verify_data (verify_data_length) in the Finished message MUST be equal to the length of the output of the hash function used for the PRF. For the mandatory TLS-LTS cipher suites this hash is always SHA-256, so the value of verify_data_length will be 32 bytes. For other suites, the size depends on the hash algorithm associated with the suite. For example for SHA-512 it would be 64 bytes.¶

• When ECDH is used to establish the premaster secret, the premaster secret value is the full elliptic curve point Q as output from the ECDH key agreement mechanism rather than the x coordinate of the point Q by itself. In other words for the uncompressed point format used in TLS-LTS, the premaster secret would be 04 || qx || qy rather than qx by itself.¶

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 build on the fact that standard TLS doesn't authenticate previously-exchanged parameters when the ServerKeyExchange message is sent:¶

• 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 Client Hello and Server Hello using the hash algorithm for the chosen cipher suite. In other words the value being signed is changed from:¶

  digitally-signed struct {
      opaque client_random[32];
      opaque server_random[32];
      ServerDHParams params;
      } signed_params;
  

  ¶

  to:¶

  digitally-signed struct {
      opaque client_server_hello_hash;
      ServerDHParams params;
      } signed_params;
  

  ¶

  For the mandatory TLS-LTS cipher suites the hash algorithm is always SHA-256, so the length of the client_server_hello_hash is 32 bytes. For other suites, the size depends on the hash algorithm associated with the suite. For example for SHA-512 it would be 64 bytes.¶

(In terms of side-channel attack prevention, it would be preferable to include a non-public quantity into the data being signed since this reduces the scope of attack from a passive to an active one, with the attacker needing to initiate their own handshakes in order to carry out their attack. However no shared secret value has been established at this point so only public data can be signed).¶

The choice of key sizes is something that will never get any consensus because there are so many different worldviews involved. TLS-LTS makes only general recommendations on best practices and leaves the choice of which key sizes are appropriate to implementers and policy makers:¶

• 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), any relevant security policies, 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 the keys periodically. For example for DH keys 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 option is to pre-generate a selection of DH parameters and choose one set at random for each new handshake, or again roll them over from time to time from the pre-generated selection, so that an attacker has to attack multiple sets of parameters rather than just one.¶

3.2. Message Formats

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, q, g } rather than { p, g }. This makes the ServerDHParams field:¶

  struct {
      opaque dh_p<1..2^16-1>;
      opaque dh_q<1..2^16-1>;
      opaque dh_g<1..2^16-1>;
      opaque dh_Ys<1..2^16-1>;
      } ServerDHParams;     /* Ephemeral DH parameters */
  

  ¶

  Note that this uses the standard DLP parameter order { p, q, g }, not the erroneous { p, g, q } order from the X9.42 DH specification.¶

• The domain parameters MUST either be compared for equivalence to a set of known-good parameters provided by an appropriate standards body or they MUST be verified as specified in FIPS 186 [FIPS-186]. Examples of the former may be found in RFC 3526 [RFC3526].¶

Note that while other sources of DH parameters exist, these should be treated with a great deal of caution. For example RFC 5114 [RFC5114] provides no source for the values used, leading to suspicions that they may be trapdoored, and RFC 7919 [RFC7919] mandates fallback to RSA if the sole DH parameter set for each key size specified in the standard isn't automatically chosen by both client and server.¶

Industry standards bodies may consider restricting domain parameters to only allow known-good values such as those referenced in the above standard, or ones generated by the standards body. This makes checking easier, but has the downside that restricting the choice to a small set of values makes them a more tempting target for well-resourced attackers. In addition it requires that the values be carefully generated, and the generation process be well-documented, to produce a so-called NUMS (Nothing Up My Sleeve) number that avoids any suspicion of it having undesirable hidden properties (the standard mentioned above, RFC 5114 [RFC5114], does not contain NUMS values).¶

In any case signing the Client/Server Hello messages and the use of Extended Master Secret makes active attacks that manipulate the domain parameters on the fly far more difficult than they would be for standard TLS.¶

3.3. Miscellaneous

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/Server Hello random data. The data SHOULD consist entirely of random bytes.¶

    [Note: A proposed downgrade-attack prevention mechanism
     may make use of these bytes, see section 3.6].

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 drops the requirement to generate the Client.random and Server.random using "a secure random number generator", typically the one used to generate encryption keys. The use of a secure/cryptographic random number generator serves no obvious purpose (all that's required is a unique value), but exposes 224 bits of the cryptographic RNG output to an attacker, allowing them to analyse and potentially attack the RNG, and by extension any crypto keys that it generates:¶

• Implementations SHOULD NOT use the raw output from a cryptographic/secure RNG that's used to generate keying material to generate the Client.random and Server.random values. Instead, they SHOULD employ a mechanism that doesn't directly expose cryptographic RNG output to attackers, for example by using the crypto RNG to seed a hash-based PRF such as the TLS PRF and using the output of that for the values.¶

3.4. Implementation Issues

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 [PKCS1], 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.¶

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.¶

TLS uses a number of crypto mechanisms, some of which are more brittle than others. The ECC algorithms used in are quite vulnerable to faults, with RSA significantly less so. Conversely, the PSK mechanisms are essentially immune to key compromise induced by faults. In terms of bulk encryption mechanisms, AES-GCM is far more vulnerable to faults than AES-CBC:¶

• Implementations SHOULD take steps to protect against fault attacks. One simple countermeasure for the public-key signature mechanisms is to use the public key to verify any signatures generated before they are sent over the wire. Other protection measures include checksumming key data held in memory, particularly where the key is stored over an extended period of time. Implementations intended to be used in harsh environments where faults are expected SHOULD consider the use of TLS-PSK in place of any of the mechanisms using public/private-key authentication, for which key compromise in the presence of faults is unlikely.¶

Authentication mechanisms for protocols run over TLS typically have separate authentication procedures for the tunnelled protocol and the encapsulating TLS session. The leads to an issue known as the channel binding problem in which the tunnelled protocol isn't tied to the encapsulating TLS session and can be manipulated by an attacker once it passes the TLS endpoint. Channel binding ties the cryptographic protection offered by TLS to the protocol that's being run over the TLS tunnel:¶

• Implementations that require authentication for protocols run over TLS SHOULD consider using channel bindings to tie the application-level protocol to the TLS session, specifically the tls_unique binding, which makes use of the contents of the first TLS Finished message sent in an exchange to bind to the tunneled application-level protocol [TLS-Channel-Bindings].¶

The original description of the tls_unique binding contains a long note detailing problems that arise due to rehandshake issues and how to deal with them. Since TLS-LTS doesn't allow rehandshakes, these problems don't exist, so no special handling is required.¶

Complexity is the enemy of security. TLS consists of just under two thousand pages of RFCs and drafts, encompassing three hundred and fifty cipher suites and sixty extensions. The fewer of these that are present, the less attack surface there is. TLS-LTS allows for the implementation of just one known-good cipher suite and one extension (used to indicate the presence of TLS-LTS), significantly reducing an implementation's attack surface.¶

• Implementations SHOULD consider selecting a single appropriate TLS-LTS cipher suite and no extensions for attack surface reduction purposes. This reduces implementation complexity, code size, and the quantity of opportunities an attacker has to compromise the protocol.¶

The TLS protocol has historically and somewhat arbitrarily been described as a state machine, which has led to numerous implementation flaws when state transitions weren't very carefully considered and enforced [TLS-Analysis-10][TLS-Analysis-13] [TLS-Analysis-15] [TLS-Analysis-16]. A safer and 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 numerous implementation errors in the past which are avoided through the use of the ladder diagram form.¶

TLS-LTS mandates the use of cipher suites that provide so-called Perfect Forward Secrecy (PFS), in which an attacker can't record sessions and decrypt them at a later date. The PFS property is however impacted by the TLS session cache and session tickets, which allow an attacker to decrypt old sessions. The session cache is relatively short-term and only allows decryption while a session is held in the cache, but the use of long-term keys in combination with session tickets means that an attacker can decrypt any session used with that key, defeating PFS:¶

• Implementations SHOULD consider the impact of using session caches and session tickets on PFS. Security issues in this area can be mitigated by using short session cache expiry times, and avoiding session tickets or changing the key used to encrypt them periodically.¶

Another form of cacheing that can affect security is the reuse of the supposedly-ephemeral DH value y = g^x mod p or its elliptic curve equivalent. Instead of computing a fresh value for each session, some servers for performance reasons compute the y value once and then reuse it across multiple TLS sessions. If this is done then an attacker can compute the discrete log value from one TLS session and reuse it to attack later sessions:¶

• Implementations SHOULD consider the impact of reusing the DH y = g^x mod p value across multiple TLS sessions, and avoid this reuse if possible. Where the reuse of y is unavoidable, it SHOULD be refreshed as often as is feasible. One way to do this is to compute it as a background task so that a fresh value is available when required.¶

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.¶

Cryptographic protocol implementations rely critically on the implementation performing extensive checking of all crypto operations to ensure that problems are detected and caught. Testing for the failure of these checks is rarely performed in implementations and test suites, and the problem is not picked up by normal testing. To deal with this issue, this specification recommends that implementations test their cryptographic mechanisms to ensure that crypto failures are detected and caught:¶

• Implementations SHOULD apply fault-injection testing to ensure that cryptographic failures are correctly caught. At a minimum, test suites SHOULD be capable of inducing faults in the client_random/server_random, the ServerDHParams/ServerECDHParams in the ServerKeyExchange, the signature value for the server key, the MAC value in the finished message, and the IV, payload data, and MAC values for messages, and the implementation MUST be able to detect these faults.¶

• One way to induce such a fault is to flip a bit in the appropriate data value in a location where the problem must be detected by cryptographic means, for example in the binary payload data rather than in an identifier or length field where it would be picked up as a decoding error.¶

• If certificate-based authentication is used, implementations SHOULD apply fault-injection testing to ensure that cryptographic failures in the certificate processing are correctly caught. At a minimum, test suites SHOULD be capable of inducing faults in the signed certificate content and the certificate signature data, and the implementation MUST be able to detect these faults.¶

• PKI provides near-unlimited scope for further checking, implementations MAY apply additional testing as required.¶

• If PSK-based authentication is used, implementations SHOULD apply fault-injection testing to ensure that failures in the PSK authentication are correctly caught. At a minimum, test suites SHOULD be capable of inducing faults in the psk_identity and the psk, and the implementation MUST be able to detect these faults.¶

3.5. Use of TLS Extensions

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 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, with the presence of tls_lts implying signature_algorithms = RSA/ECDSA + SHA-256, elliptic_curves = P256, ec_point_formats = uncompressed, encrypt_then_mac = TRUE, and extended_master_secret = TRUE. Implementations that wish to communicate with legacy implementations and wish to use the capabilities described by the extensions outside of TLS-LTS MUST include these extensions in their Client Hello.¶

Conversely, although all of the above extensions are implied by TLS-LTS, if a client requests TLS-LTS in its Client Hello then it doesn't expect to see them returned in the Server Hello if TLS-LTS is indicated. The handling of extensions during the Client/Server Hello exchange is therefore as follows:¶

TLS-LTS capabilities are indicated purely by the presence of the tls_lts extension, not the plethora of other extensions that it's comprised of. This allows an implementation that needs to be backwards-compatible with legacy implementations to specify individual options for use with non-TLS-LTS implementations via a range of extensions, and specify the use of TLS-LTS via the tls_lts extension.¶

3.6. Downgrade Attack Prevention

The use of the TLS-LTS improvements relies on an attacker not being able to delete the TLS-LTS extension from the Client/Server Hello messages. This is achieved through the SCSV [SCSV] signalling mechanism.¶

[If SCSV is used then insert required boilerplate here, however this will also require banning weak cipher suites like export ones, which is a bit interesting in that it'll required banning something that in theory has already been extinct for 15 years. A better option is to refer to Karthikeyan Bhargavan's rather clever idea on anti-downgrade signalling, which is a more reliable mechanism than SCSV].¶

5.1. Security Properties Provided by TLS-LTS

If implemented correctly, TLS will provide confidentiality and integrity protection of traffic, and guarantees liveness of the communications. In some circumstances it also provides authentication, see below. Apart from that, it provides no other guarantees.¶

5.2. Security Properties Not Provided by TLS-LTS

TLS does not in general protect against spoofing (most commonly encountered on the web as phishing). The one exception is when one of the PSK mechanisms, which provides mutual cryptographic authentication of client and server, is used. PKI, a mechanism outside of TLS, is expected to provide protection against spoofing, but in practice rarely does so.¶

Unless implemented very carefully, TLS does not provide strong protection against side-channel attacks. While this document specifies countermeasures against timing and oracle side-channels that should be employed, these are very difficult to get right and not always effective.¶

TLS provides no real protection against traffic analysis. While the protocol specification contains provisions for message padding, this has little effect on attackers in practice.¶

In the presence of implementation flaws (bugs) or hardware or software errors, some TLS mechanisms may fail catastrophically. AES-GCM is fatally vulnerable to nonce reuse or repeated counter/IV values. AES-CBC in contrast can be arbitrarily abused, for example by setting the IV to the constant value zero, with at most a slight degradation in security (reduction to ECB mode) rather than a complete loss of security.¶

TLS provides no availability guarantees. In fact since it increases susceptibility to failures, either genuine or artificially-induced (for example due to an expired certificate that's otherwise fully valid), it reduces overall availability.¶

TLS provides no guarantees of non-repudiation, access control, or authorisation. These services must be provided by external mechanisms.¶

In short, TLS provides confidentiality (if the crypto is implemented properly and steps are taken to protect against faults and failures), integrity protection, and in some limited cases authentication. It does not provide any other service. If further security services are required, these must be provided through additional, external mechanisms.¶

TLS is a cryptographic protocol, not security pixie dust. Before deciding to employ it, you should evaluate whether it actually provides the security services that you think it does.¶