TLS Working Group P. Gutmann
Internet-Draft University of Auckland
Intended status: Standards Track April 6, 2016
Expires: October 8, 2016
TLS 1.2 Long-term Support Profile
draft-gutmann-tls-lts-03
Abstract
This document specifies a profile 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 profile 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.
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 http://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 October 8, 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
(http://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
Gutmann Expires October 8, 2016 [Page 1]
Internet-Draft TLS-LTS April 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. TLS-LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The TLS-LTS Profile . . . . . . . . . . . . . . . . . . . . . 3
3.1. Encryption/Authentication . . . . . . . . . . . . . . . . 3
3.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5
3.3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Implementation Issues . . . . . . . . . . . . . . . . . . 6
3.5. Use of TLS Extensions . . . . . . . . . . . . . . . . . . 8
3.6. Downgrade Attack Prevention . . . . . . . . . . . . . . . 9
3.7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
TLS [2] and DTLS [4], 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, this document 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 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.
Gutmann Expires October 8, 2016 [Page 2]
Internet-Draft TLS-LTS April 2016
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 for 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
http://www.cs.auckland.ac.nz/~pgut001/pubs/tls-lts.txt 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].
2. TLS-LTS
The use of TLS-LTS is negotiated via TLS/DTLS extensions as defined
in TLS Extensions [3]. 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 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 the TLS-LTS profile unless both sides have
successfully exchanged tls_lts extensions.
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:
Gutmann Expires October 8, 2016 [Page 3]
Internet-Draft TLS-LTS April 2016
o 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.
[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:
o TLS-LTS implementations MUST implement encrypt-then-MAC [5] 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:
o TLS-LTS implementations MUST implement extended master secret [7]
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:
o 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. In 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:
o When generating the ServerKeyExchange signature, the signed_params
value is updated to replace the client_random and server_random
Gutmann Expires October 8, 2016 [Page 4]
Internet-Draft TLS-LTS April 2016
with a hash of the full ClientHello and ServerHello. 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;
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:
o 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.
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:
Gutmann Expires October 8, 2016 [Page 5]
Internet-Draft TLS-LTS April 2016
o TLS-LTS implementations MUST send the DH domain parameters as { p,
g, q } rather than { p, g }. This makes the ServerDHParams field:
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 */
The domain parameters MUST be verified as specified in FIPS 186
[8].
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:
o 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:
o TLS-LTS implementations MUST NOT implement compression or
rehandshake.
3.4. Implementation Issues
TLS-LTS requires that RSA signature verification be done as encode-
then-compare, which fixes all known padding-manipulation issues:
o TLS-LTS implementations MUST verify RSA signatures by using
encode-then-compare as described in PKCS #1 [9], 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:
o 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
Gutmann Expires October 8, 2016 [Page 6]
Internet-Draft TLS-LTS April 2016
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:
o 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.
o 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:
o 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.
The TLS-LTS profile 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:
o 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.
Gutmann Expires October 8, 2016 [Page 7]
Internet-Draft TLS-LTS April 2016
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:
o The signature_algorithms extension, since the use of SHA-256 with
RSA or ECDSA is implicit in TLS-LTS.
o The elliptic_curves and ec_point_formats extensions, since the use
of P256 with uncompressed points is implicit in TLS-LTS.
o 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.
o The encrypt_then_mac extension, since the use of encrypt-then-MAC
is implicit in TLS-LTS.
o 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.
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
Gutmann Expires October 8, 2016 [Page 8]
Internet-Draft TLS-LTS April 2016
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 the TLS-LTS profile 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 [6] 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].
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.
Gutmann Expires October 8, 2016 [Page 9]
Internet-Draft TLS-LTS April 2016
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 [2].
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.
Gutmann Expires October 8, 2016 [Page 10]
Internet-Draft TLS-LTS April 2016
[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.
Gutmann Expires October 8, 2016 [Page 11]
Internet-Draft TLS-LTS April 2016
Author's Address
Peter Gutmann
University of Auckland
Department of Computer Science
University of Auckland
New Zealand
Email: pgut001@cs.auckland.ac.nz
Gutmann Expires October 8, 2016 [Page 12]