TLS Working Group P. Gutmann
Internet-Draft University of Auckland
Intended status: Standards Track March 20, 2016
Expires: September 21, 2016

TLS 1.2 Long-term Support Profile


This document specifies a profile of TLS 1.2 for long-term support, one that represents what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This represents a stable, known-good profile that can be deployed now to systems that can't roll out patches every month or two when the next attack on TLS is published.

Status of This Memo

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

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 21, 2016.

Copyright Notice

Copyright (c) 2016 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 ( 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.

Table of Contents

1. Introduction

TLS [TLS] and DTLS [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 profile 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 it takes inspiration from numerous published analyses of TLS [10] [11] [12] [13] [14] [15] [16] [17] [18] 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 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 use of TLS, particularly in the embedded systems that are most in need of a long-term stable protocol profile.

    [Note: Because this is a rapidly-evolving document but the posting
     blackout before IETF 95 makes putting new versions online in the
     usual location difficult, updates will temporarily be posted to for comment
     until the draft-submission process is open again].

1.1. Conventions Used in This Document

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 [TLS-Ext]. On connecting, the client includes the tls_lts extension in its client_hello if it wishes to use the TLS-LTS profile. If the server is capable of meeting this requirement, it responds with an tls_lts in its server_hello. The "extension_type" value for this extension SHALL be TBD (0xTBD) and the "extension_data" field of this extension SHALL be empty. The client and server MUST NOT use the TLS-LTS profile unless both sides have successfully exchanged tls_lts extensions.

2.1. Rationale

The use of extensions precludes use with SSL 3.0, but then it's likely that anything still using this nearly two decades-old protocol will be vulnerable to any number of other attacks anyway, so there seems little point in bending over backwards to accomodate SSL 3.0.

3. The TLS-LTS 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.

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:

    [Question: There's a gap in the suites with
     TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 missing, although it's
     present for all manner of non-AES ciphers, should we specify
     TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 or fill the current hole
     with TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256?].

TLS-LTS only permits encrypt-then-MAC, not MAC-then-encrypt, fixing 20 years of attacks on this mechanism:

TLS-LTS drops the IPsec cargo-cult MAC truncation, which serves no obvious purpose and leads to security concerns:

TLS-LTS recommends that implementations take measures to protect against side-channel attacks:

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:

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

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:

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.

    [Question: Should the PRF be replaced with HKDF?  There's no
     pressing need for this, but it could be part of the general

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:

struct {
    opaque dh_p<1..2^16-1>;
    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 */

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:

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 drops compression and rehandshake, which have led to a number of attacks:

3.4. Implementation Issues

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:

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:

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.

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:

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.

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 handshake messages. This is achieved through the SCSV [TLS-Analysis-1] 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].

3.7. Rationale

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.

4. Security Considerations

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.

5. IANA Considerations

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

6. Acknowledgements

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

7. References

7.1. Normative References

, "
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[3] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions", RFC 6066, January 2011.
[4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[5] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, September 2014.
[6] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, April 2015.
[7] Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, A. and M. Ray, Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, September 2015.
[8]Digital Signature Standard (DSS)", FIPS 186, July 2013.
[9] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.

7.2. Informative References

[10] Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A., Strub, P. and S. Zanella-Beguelin, "Proving the TLS handshake secure (as is)", Springer-Verlag LNCS 8617, August 2014.
[11] Brzuska, C., Fischlin, M., Smart, N., Warinschi, B. and S. Williams, "Less is more: relaxed yet compatible security notions for key exchange", IACR ePrint archive 2012/242, April 2012.
[12] Dowling, B. and D. Stebila, "Modelling ciphersuite and version negotiation in the TLS protocol", Springer-Verlag LNCS 9144, June 2015.
[13] Firing, T., "Analysis of the Transport Layer Security protocol", June 2010.
[14] Gajek, S., Manulis, M., Pereira, O., Sadeghi, A. and J. Schwenk, "Universally Composable Security Analysis of TLS", Springer-Verlag LNCS 5324, November 2008.
[15] Jager, T., Kohlar, F., Schaege, S. and J. Schwenk, "On the security of TLS-DHE in the standard model", Springer-Verlag LNCS 7417, August 2012.
[16] Giesen, F., Kohlar, F. and D. Stebila, "On the security of TLS renegotiation", ACM CCS 2013, November 2013.
[17] Meyer, C. and J. Schwenk, "Lessons Learned From Previous SSL/TLS Attacks - A Brief Chronology Of Attacks And Weaknesses", Cryptology ePrint Archive 2013/049, January 2013.
[18] Krawczyk, H., Paterson, K. and H. Wee, "On the security of the TLS protocol", Springer-Verlag LNCS 8042, August 2013.

Author's Address

Peter Gutmann University of Auckland Department of Computer Science University of Auckland, New Zealand EMail: