University of Auckland

Department of Computer Science University of Auckland Auckland New Zealand pgut001@cs.auckland.ac.nz

Security Area TLS Working Group Internet-Draft This document specifies an update of TLS 1.2 for long-term support, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This represents a stable, known-good version that can be deployed to systems that can't roll out a new set of patches every month or two when the next attack on TLS is published.

TLS and DTLS, by nature of their enormous complexity and the inclusion of large amounts of legacy material, contain numerous security issues that have been known to be a problem for many years and that keep coming up again and again in attacks (there are simply too many of these to provide references for, and in any case more will have been published by the time you read this). This document presents a minimal, known-good set of mechanisms that defend against all currently-known weaknesses in TLS, that would have defended against them ten years ago, and that have a good chance of defending against them ten years from now, providing the long-term stability that's required by many systems in the field. In particular, this document takes inspiration from numerous published analyses of TLS along with two decades of implementation and deployment experience to select a standard interoperable feature set that provides the best chance of long-term stability and resistance to attack. This is intended for use in systems that need to run in a fixed configuration for a long period of time after they're deployed, with little or no ability to roll out patches every month or two when the next attack on TLS is published. Unlike the full TLS 1.2, TLS-LTS is not meant to be all things to all people. It represents a fixed, safe solution that's appropriate for users who require a simple, secure, and long-term stable means of getting data from A to B. This represents the majority of the non-browser uses of TLS, particularly for embedded systems that are most in need of a long-term stable protocol definition.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The use of TLS-LTS is negotiated via TLS/DTLS extensions as defined in TLS Extensions. On connecting, the client includes the tls_lts extension in its client_hello if it wishes to use TLS-LTS. If the server is capable of meeting this requirement, it responds with a tls_lts extension in its server_hello. The "extension_type" value for this extension MUST be TBD (0xTBD) and the "extension_data" field of this extension is empty. The client and server MUST NOT use TLS-LTS unless both sides have successfully exchanged tls_lts extensions. The use of TLS-LTS can potentially change during one or more rehandshakes. Implementations MUST retain the current TLS-LTS session state across all rehandshakes for that session. In other words if TLS-LTS is enabled for the current session then the renegotiated session MUST also use TLS-LTS.

TLS-LTS 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. 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 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 to protect handshake and crypto parameters. TLS-LTS drops the IPsec cargo-cult MAC truncation in the Finished message, which serves no obvious purpose and leads to security concerns: 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 TLS-LTS this is always SHA-256, so the value of verify_data_length is 32 bytes.

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 ClientHello and ServerHello. In other words the value being signed is changed from:

to:

As with the hash used in verify_data in the Finished message, the hash of the helo messages is always SHA-256, so the length of the client_server_hello_hash is 32 bytes. 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 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 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. 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. 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 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. 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 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. Conversely, although encrypt_then_mac and extended_master_secret are implied by TLS-LTS, a client requesting TLS-LTS but not encrypt_then_mac and/or extended_master_secret in its Client Hello doesn't expect to see either of these indicators returned in the Server Hello. TLS-LTS servers MUST NOT return encrypt_then_mac and/or extended_master_secret indicators to the client unless this has been explicitly requested by the client. Note that TLS-LTS capabilities are indicated 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.

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 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 a currently work-in-progress draft on anti-downgrade signalling, which is a more reliable mechanism than SCSV].

A question that may be asked at this point is, why not use TLS 1.3 instead of creating a secure update 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 specification 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 specification 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.

This document defines a minimal, known-good subset of TLS 1.2 that attempts to address all known weaknesses in the protocol, mostly by simply removing known-insecure mechanisms but also by updating the ones that remain to take advantage of many years of security research and implementation experience.

IANA has added the extension code point TBD (0xTBD) for the tls_lts extension to the TLS ExtensionType values registry as specified in TLS.

The author would like to thank the members of the TLS mailing list for their feedback on this document.

Harvard University General keyword Independent RTFM, Inc. Huawei RTFM, Inc. Stanford University University of Auckland Google Switzerland Gmbh Google Inc. Inria Paris-Rocquencourt Inria Paris-Rocquencourt Inria Paris-Rocquencourt Google Inc. Microsoft Corp. Philipps-Universitaet Marburg RSA Laboratories