| TLS Working Group | P. Gutmann |
| Internet-Draft | University of Auckland |
| Intended status: Standards Track | March 22, 2018 |
| Expires: September 23, 2018 |
TLS 1.2 Update for Long-term Support
draft-gutmann-tls-lts-10
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 23, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 too many of these to provide references for in the standard manner, 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. This long-term stability is particularly important in light of the fact that widespread mainstream adoption of new versions of TLS has been shown to take 15 years or more [29], with adoption in embedded environments taking even longer.
In particular, this document takes inspiration from numerous published analyses of TLS [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] 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, as well as guidance on implementing this feature set in a sound manner. 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.
[Note: Although this specification is present as a draft, it
has been stable since -03 and is already supported in a
number of deployed implementations. The specification is
unlikely to change before its final publication, and may be
regarded as stable and representative of the final
published form.
There is currently a TLS 1.2 LTS test server running at
either https://82.94.251.205:8443 or 82.94.251.197:8443
depending on the load balance. This uses the extension
value 26 until a value is permanently assigned for LTS use.
To connect, your implementation should accept whatever
certificate is presented by the server or use PSK with
name = "plc", password = "test". For embedded systems
testing, note that the this is a conventional web server,
not an IED/RTU/PLC, that talks HTTP and not DNP3 or
ICCP/TASE.2, so you'll get an error if you try and connect
with a PLC control centre that expects one of those
protocols].
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 [1].
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 26 (0x1A, see IANA Considerations below) 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.
Note that the TLS-LTS extension applies to TLS 1.2, not to any earlier version of TLS. If a client requests the use of TLS-LTS in its client_hello but the server falls back to TLS 1.1 or earlier, it MUST NOT indicate the use of TLS-LTS in its server_hello.
In the case of session resumption, once TLS-LTS has been negotiated implementations MUST retain the use of TLS-LTS across all subsequent resumed sessions. In other words if TLS-LTS is enabled for the current session then the resumed session MUST also use TLS-LTS. If a client or server attempts to resume a TLS-LTS session as a non-TLS-LTS session then the peer MUST abort the handshake.
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 prevent or at least 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:
[Note: TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 is based on
draft-ietf-tls-ecdhe-psk-aead, currently still
progressing as an IETF draft, the reference will be
updated to the full RFC once it's published].
TLS-LTS only permits encrypt-then-MAC, not MAC-then-encrypt, fixing 20 years of attacks on this mechanism:
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:
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:
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:
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
digitally-signed struct {
opaque client_server_hello_hash;
ServerDHParams params;
} signed_params;
(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:
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.
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:
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 while other sources of DH parameters exist, these should be treated with a great deal of caution. For example RFC 5114 provides no source for the values used, leading to suspicions that they may be trapdoored, and RFC 7919 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, 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.
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:
[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 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:
TLS-LTS requires that RSA signature verification be done as encode-then-compare, which fixes all known padding-manipulation issues:
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:
TLS-LTS recommends that implementations take measures to protect against side-channel attacks:
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:
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:
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.
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 [20][23] [25] [26]. 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:
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:
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:
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:
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:
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:
| Client Hello | Server Chooses | Server Hello |
|---|---|---|
| TLS-LTS | TLS-LTS | TLS-LTS |
| TLS-LTS, EMS/EncThenMAC/... | TLS-LTS | TLS-LTS |
| TLS-LTS, EMS/EncThenMAC/... | EMS/EncThenMAC/... | EMS/EncThenMAC/... |
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.
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 Karthikeyan Bhargavan's rather clever idea on anti-downgrade signalling, which is a more reliable mechanism than SCSV].
This section addresses the question of why this document specifies a long-term support profile for TLS 1.2 rather than going to TLS 1.3. The reason for this is twofold. Firstly, we know that TLS, which has become more or less the universal substrate for secure communications over the Internet, has extremely long deployment times. Much of this information is anecdotal (although there are a large number of these anecdotes), however one survey carried out in 2015 and 2016 illustrates the scope of the problem. This study found that the most frequently-encountered protocol (in terms of use in observed Internet connections) was the fifteen-year-old TLS 1.0, with the next most common, TLS 1.2, lagging well behind [29]. This was on the public Internet, in the non-public arena (where much of the anecdotal evidence comes from, since it's not possible to perform a public scan) the most common protocol appears to be TLS 1.0 (which includes it being hardcoded into specifications like the widely-used DPWS and IEC 62351), with significant numbers of systems still using the twenty-year-old SSLv3.
Given that TLS 1.3 is almost a completely new protocol compared to the incremental changes from SSLv3 to TLS 1.2, and that the most widely-encountered protocol version from that branch is more than fifteen years old, it's likely that TLS 1.3 deployment outside of constantly-updated web browsers may take one to two decades, or may never happen at all given that a move to TLS 1.2 is an incremental change from TLS 1.0 while TLS 1.3 requires the implementation of a new protocol. This document takes the position that if a protocol from the TLS 1.0 - 1.2 branch will remain in use for decades to come, it should be the best form of TLS 1.2 available.
The second reason why this document exists has already been mentioned above, that while TLS 1.0 - 1.2 are all from the same fairly similar family, TLS 1.3 is an almost entirely new protocol. As such, it 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 a 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 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 and the huge deployed base of TLS 1.0 - 1.2 implementations to update TLS 1.2 into a known-good form 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 experimental ideas, mechanisms, and algorithms, and hoping that it can be deployed in less than a decade- or multi-decade time frame. The intent is to create a long-term stable protocol specification that can be deployed once as a minor update to existing TLS implementations, not deployed as a new from-scratch implementation and then patched, updated, and fixed constantly for the lifetime of the equipment that it's used with.
This section provides an implementer's checklist of the core features that are required for a TLS-LTS implementation. This doesn't cover all of the requirements in this document, merely the minimum ones required for an interoperable implementation. See the remainder of this document for the full set of requirements.
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. As an example of its efficacy, several attacks on standard TLS that emerged after this document was first published were countered by the mechanisms specified here, with no updates or changes to TLS-LTS implementations being necessary to deal with them.
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.
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.
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 contributors from various embedded system vendors for their feedback on this document.