Network Working Group A. Langley Internet-Draft Google Inc Expires: April 4, 2014 P. Hoffman VPN Consortium Oct 2013 Operational concerns for implementations of Transport Layer Security draft-agl-wpkops-tlsstack-00 Abstract Abstract. 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 April 4, 2014. Copyright Notice Copyright (c) 2013 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Langley & Hoffman Expires April 4, 2014 [Page 1] Internet-Draft TLS stack operations Oct 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Handshake recommendations . . . . . . . . . . . . . . . . . . 5 3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Certificates . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 7 3.6. ClientKeyExchange . . . . . . . . . . . . . . . . . . . . 7 3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Application data recommendations . . . . . . . . . . . . . . . 9 4.1. CBC ciphersuites . . . . . . . . . . . . . . . . . . . . . 9 4.2. Record sizes . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. AES-GCM nonces . . . . . . . . . . . . . . . . . . . . . . 9 5. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Langley & Hoffman Expires April 4, 2014 [Page 2] Internet-Draft TLS stack operations Oct 2013 1. Introduction This text documents operational concerns when implementing TLS [RFC5246]. As with any protocol in wide deployment, bugs and varying interpretations of the standard have resulted in an implementation ecosystem which contains many potholes. Operating TLS over the modern Internet requires knowledge of these features of the implementation landscape that we hope to describe here. Langley & Hoffman Expires April 4, 2014 [Page 3] Internet-Draft TLS stack operations Oct 2013 2. Requirements Notation 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 RFC 2119 [RFC2119]. Langley & Hoffman Expires April 4, 2014 [Page 4] Internet-Draft TLS stack operations Oct 2013 3. Handshake recommendations 3.1. ClientHello As noted in RFC 5246, section E.1, the correct value for the record version number for the first record from a client was unclear prior to TLS 1.2. In practice sending a value of 0x0301 minimises compatibility issues. (Some server implementations will use the record version for version negotiation instead of the ClientHello version.) Some implementations are known to hang the connection when the record containing the ClientHello is larger than 255 bytes. There is no known workaround for this except to ensure that the ClientHello remains small. Thankfully an implementation that both has this bug and supports SessionTickets has not been observed, but some do return Session IDs and so failure may be intermittent as attempted resumptions push the ClientHello over the this size limit. Other implementations are known to hang the connection if the record containing the ClientHello is larger than 255 bytes and the record version number is greater than 0x0301. Setting the version to 0x0301, as recommended above, also solves this issue. Some implementations will fail a connection when the "client_version" takes certain values. For example, offering TLS 1.2 in the ClientHello may cause some servers to return a fatal alert or simply close the TCP connection. The only workaround is version fallback (see later section). The majority of implementations will fail if the offered version is greater than 0x03ff. Most implementations follow the RFC and set "random.gmt_unix_time" to a timestamp value. However, implementations should not depend on this: in order to avoid fingerprinting, some implementations will fill it with random bytes. Cipher suites that are not supported in the TLS version advertised (i.e. AEAD cipher suites prior to TLS 1.2) should not be included in the list of advertised cipher suites. Some server implementations will select them despite the TLS version and it's unclear what the correct behaviour is in such a situation. Due to information leaks arising from the size of compressed records, compression methods other than null should not be advertised nor accepted without very careful consideration of the implications. The use of DEFLATE compression will cause OpenSSL prior to version 0.9.8c to intermittently fail to process compressed Finished messages due to a work around of a previous padding bug. Langley & Hoffman Expires April 4, 2014 [Page 5] Internet-Draft TLS stack operations Oct 2013 3.2. Extensions The presence of any extensions, or certain extensions, may cause a server to fail a connection. Anecdotally, the "status_request" extension is most likely to cause issues. The only workaround is version fallback (see later section). Some versions of Android fail when the server returns an empty Next Protocol Negotiation extension. Rather than an empty extension, servers should omit the extension entirely. Some hardware tokens used for client certificate signing implement only SHA-1 so, even when the TLS stack implements TLS 1.2, supporting SHA-1 signatures in the "signature_algorithms" extension may be needed to inter-operate with these devices. When implementing a server supporting both ALPN and NPN, NPN should be ignored when an ALPN extension is also present as NPN will eventually be removed and it's best to exercise the code path that will be dominant in the future. The "server_name_indication" extension is increasingly required for compatibility with virtually hosted servers and should be included by clients whenever the hostname of the server is known. 3.3. ServerHello Several of the same considerations in the ClientHello section also apply to the ServerHello, but will not be repeated here. Cipher suites that are not supported by the negotiated TLS version should not be selected as the cipher suite for the connection. Some client implementations will fail the connection in the event that the server selects a cipher suite that is not defined for the negotiated TLS version. 3.4. Certificates Servers should endeavor to ensure that a full certificate chain is configured. It's a common mistake for servers to omit necessary intermediate certificates. Servers may wish to attempt to validate the configured certificates against a set of roots, or may heuristically reject single certificate chains where the certificate is not self-signed. Some client implementations will perform "AIA chasing" in the event that a certificate chain is incomplete. This involves fetching the missing certificates by downloading them from the URLs given in the Langley & Hoffman Expires April 4, 2014 [Page 6] Internet-Draft TLS stack operations Oct 2013 Authority Information Access extensions of the certificate. Not all clients will do this however so it should not be relied upon. It also makes TLS connections slow and less reliable. Servers should endeavor to ensure that the certificate chain is in the correct order. It's a common mistake for the second and subsequent certificates to be reordered. This is easy to detect by checking the Issuer and Subject (or key IDs) of adjacent certificates. However, nearly all client implementations are capable of reordering received certificate chains to workaround this issue. Servers should not send a self-signed certificate as part of the certificate chain unless it's the sole certificate. It's a common mistake to include a, superfluous, CA root certificate in the transmitted chain. Servers should not include unrelated certificates in the certificate chain. Checking for out of order chains should also cover this case. Some versions of OS X 10.8 will advertise ECDSA support but will fail to support it if selected by the server. The workaround for this is to fingerprint the ClientHello messages of OS X and not select ECDSA when detected. 3.5. ServerKeyExchange Some servers will negotiate DHE cipher suites, but attempt to use tiny Diffie-Hellman groups (for example, with a 256-bit modulus). It is safe to reject DH groups less than 512-bits on the modern Internet, but 512-bit groups are still worryingly weak. Some clients will retry a connection without offering DHE cipher suites in the event that the server uses a small DH group. 3.6. ClientKeyExchange The version number in the RSA EncryptedPreMasterSecret is the cause of much complication. Careful reading of RFC 5246, section 7.4.7.1 is required. In addition to that text, when renegotiating, some versions of SChannel require that the version in the EncryptedPreMasterSecret match the version in the initial ClientHello, not the renegotiation ClientHello. Thus it's recommended that, when renegotiating a connection, RFC 5246, section E.1 be disregarded when it specifies that a client should always use the highest version number that it knows that a server supports. Instead, when renegotiating, a client should repeat the version used in the initial ClientHello. Langley & Hoffman Expires April 4, 2014 [Page 7] Internet-Draft TLS stack operations Oct 2013 3.7. Fallback Several incompatibilities described in this document cause the TLS connection to fail. This failure can take the form of a TCP reset, abort or fatal TLS error. In all cases, the TLS connection cannot be used and, without further action by the client, communication will not be possible with the buggy implementation. In order to achieve maximum compatibility, several client implementations will perform one or more "fallback" steps in the event of a failed TLS handshake. A typical fallback path from a failed TLS 1.2 handshake involves retrying with TLS 1.1, then TLS 1.0 and, finally, with SSLv3 with all extensions removed. While this has compatibility benefits, it also certainly has security concerns. Firstly, in versions prior to TLS 1.1, there is no explicit initialisation vector for CBC encrypted records and workarounds are required (see next section). Fallbacks can be triggered by transient network events as well as buggy implementations and a fallback which eliminates extensions perforce removes the "server_name_indication" extension. This can cause certificate errors if the server requires SNI - a very surprising error that often causes alarm. Eliminating extensions also eliminates elliptic-curve support and, for servers that support ECDHE but not DHE, this can result in a meaningful reduction in security as forward-security is eliminated. This is troubling as fallbacks can be triggered by network attackers. Lastly, in versions prior to TLS 1.2, AEAD cipher suites are not supported and there are now serious concerns with all non-AEAD cipher suites in TLS. Langley & Hoffman Expires April 4, 2014 [Page 8] Internet-Draft TLS stack operations Oct 2013 4. Application data recommendations 4.1. CBC ciphersuites Prior to TLS 1.1, there was no per-record initialisation vector for CBC records. This leads to known attacks [Cite Rogaway '95, Bard '04 and '06, Duong and Rizzo '11]. In order to repel these attacks in prior versions of TLS, implementations should split each CBC encrypted record in two: the first should have a single byte of application data and the second should have the remainder of the data. The MAC of the first record can be assumed to be unpredictable to the attacker and this serves to randomize the IV in a backwards- compatible fashion. Leaving the first record empty may appear to be a more elegant solution, but is known to cause compatibility issues as some implementations interpret an empty record as EOF. 4.2. Record sizes The maximum size of a TLSPlaintext structure is 16KB. However, because a TLS record only be processed once the whole record has been received, this can interact poorly with TCP congestion control. At the beginning of a connection, when the TCP congestion window is still opening up, a large TLS record can cause application data to stall for several round trips as the whole record is transmitted. For this reason, the ideal TLS record size at the beginning of a connection is such that it exactly fits into a lower level protocol frame. Since such size information is often not available across protocol layers, a TLSPlaintext size of 1350 bytes has been found to work well in most cases. If a connection is being used for large data transfers then a larger TLS record allows processing overhead to be better amortised. For this reason, once the TCP connection has transferred a certain amount of data, adjusting to larger records may be advantageous. As long as zero-length records are not created, no compatibility issues have been observed due to adjusting record sizes. 4.3. AES-GCM nonces AES-GCM, when used in TLS 1.2, specifies that each record contains an 8-byte nonce which is appended to a (per-connection) 4-byte value in order to produce the AES-GCM nonce for that record. Since nonce reuse is devastating to the security of AES-GCM, and the 8-byte value is small, it's recommended that implementations use the TLS sequence number as this, 8-byte value. Using random values carries an unacceptably high probability of nonce reuse under plausible scenarios. Langley & Hoffman Expires April 4, 2014 [Page 9] Internet-Draft TLS stack operations Oct 2013 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Langley & Hoffman Expires April 4, 2014 [Page 10] Internet-Draft TLS stack operations Oct 2013 Authors' Addresses Adam Langley Google Inc Email: agl@google.com Paul Hoffman VPN Consortium Email: paul.hoffman@vpnc.org Langley & Hoffman Expires April 4, 2014 [Page 11]