Proposal to Change the Default TLS Ciphersuites Offered by Browsers

Proposal

Let’s change the TLS ciphersuites offered by default in browsers to this ordered sequence:

In addition, let's have browsers agree on the following related behaviors:

• Clients should send the renegotation_info extension in every client hello except for SSL 3.0 client hellos. Clients should not send the TLS_EMPTY_RENEGOTIATION_INFO_SCSV psuedo-ciphersuite except when they are using a SSL 3.0 client hello.
• In the supported elliptic curves extension (EllipticCurveList) in the client hello, the client should offer the NIST P-256 and P-384 curves, P-256 first.
• Clients should send an ec_point_formats extension with a single element, uncompressed.
• In the signature algorithms extension in the client hello, the client should offer the following signature algorithms, in order: SHA256-RSA, SHA384-RSA, SHA1-RSA, SHA256-ECDSA, SHA384-ECDSA, SHA1-ECDSA, SHA256-DSA, SHA1-DSA.

The rest of this document is the rationale for this proposal.

Require strong encryption and authentication.

We should not support unauthenticated key exchange, export ciphersuites, ciphersuites with NULL encryption, or ciphersuites with NULL authentication.

Be consistent across platforms.

The ciphersuite order should be optimized for ARM because that is the most performance-sensitive platform we have now. We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop.

Prefer ephemeral cipher key exchange. Do not add any new non-ephemeral-key-exchange ciphersuites.

Ephemeral key exchange ciphersuites offer “Perfect Forward Secrecy.” This property ensures that, in the event that the server's private key is compromised, previously-encrypted traffic cannot be read. All the TLS_ECDHE_* and TLS_DHE_* ciphersuites proposed offer this feature, but the TLS_RSA_* ciphersuites do not. SSL Labs: Deploying Forward Secrecy or SSL: Intercepted today, decrypted tomorrow are good introductions to this topic in the context of recent newsworthy events.

Allow ephemeral key exchange with RSA certificates without requiring the use of ECDHE.

Ephemeral key exchange is extremely important. Almost every certificate on the internet today is an RSA certificate. Many servers do not implement ECDHE for various reasons, and this is not likely to change any time soon. Consequently, it is important that browsers support the DHE key exchange with RSA certificates.

Be compatible with web servers and with other browsers.

Having a consensus amongst browsers on which ciphersuites to offer helps to ensure interoperability. Also, implementations agreeing on the same ciphersuites in the same order would be important progress towards reducing fingerprinting through TLS handshake information. (See HTTP Client Fingerprinting Using SSL Handshake Analysis for background on the fingerprinting issue.)

This proposal is mostly compatible with what Chrome and MSIE do, except that this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added. Because these ciphersuites require TLS 1.2, and since there are very, very few TLS-1.2-only websites, it is unlikely that there will be compatibility issues with excluding these ciphersuites.

Prefer ECDHE ciphersuites over DHE ciphersuites.

There is a TLS extension that allows the client and server to negotiate parameters for ECDHE, but there is no such negotiation mechanism for DHE ciphersuites. The lack of such a mechanism for DHE is extremely unfortunate because there are many servers on the internet which use DHE keys that are too small (less than 1024 bits) that we would rather negotiate another ciphersuite with. Consequently, extraordinary effort is needed to maintain compatibility with sites that use DHE ciphersuites correctly while still avoiding problems caused by weak DHE keys. Putting ECDHE before DHE helps avoid the issue in at least some cases. Plus, ECDHE is much faster than DHE.

Prefer faster over slower.

When using ephemeral key exchange, the client has to verify the server's signature of the (EC)DHE parameters. Since RSA signature verification is faster than ECDSA signature verification, clients should list RSA ciphersuites ahead of ECDSA ciphersuites. However, since ECDSA signing is faster than RSA signing, servers are better off preferring ECDSA signatures over RSA certificates when server signing performance is a bottleneck.

When comparing AES-128-CBC, AES-256-CBC, and 3DES-CBC, the smaller-keyed algorithms have roughly the same security properties to the larger-key algorithms (See “New Attack on AES” and the FAQ on the attacks. 3DES is even more expensive, even before taking into account hardware optimizations like AES-NI that are becoming commonplace.) Accordingly, the encryption ciphers are ranked AES-128 > AES-256 > 3DES.

The current ordering may need to be fine-tuned. It is based on some assumptions that have not been verified yet. In particular, it has been assumed, but not verified, that all AES-128 ciphersuites are more efficient than all AES-256 ciphersuites, regardless of the authentication algorithm. Similarly, it has been assumed that AES-GCM is superior to all AES-HMAC algorithms. Research demonstrating that these assumptions are wrong (on ARM) could be used to improve the ordering.

Minimize the number of ciphersuites offered.

In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes. This motivated them to trim the ciphersuites being offered by Chrome in order to ensure that the ClientHello is less than 256 bytes. The same concern almost certainly applies to other browsers to prevent compatibility regressions, though it is unclear how many servers actually suffer from this defect. Note that this affects the practicality of deploying the ALPN extension for HTTP/2.0 and other extensions.

Years ago, Mozilla added Camellia ciphersuites on the understanding that they were necessary for use in Japan. Now this seems to not be the case, since neither Chrome nor Internet Explorer are supporting them. Similarly, years ago Mozilla added a SEED-based ciphersuite to help South Korea migrate away from ActiveX-based e-commerce. That choice also seems to have had no practical positive effect, and other browsers are not offering any SEED-based ciphersuites in their default configurations. Also, the only SEED-based ciphersuite Mozilla has been supporting uses non-ephemeral RSA key exchange. Accordingly, now is the time to drop support for these ciphersuites.

This proposal excludes all TLS_DH_* and TLS_ECDH_* ciphersuites because they do not support ephemeral key exchange, because they are practically never used, and because major browsers other than Firefox do not enable them by default. However, see the section on Ephemeral Certificates below.

This proposal does not include the new HMAC-SHA256 or HMAC-SHA384 ciphersuites that were added in TLS 1.2 since there is not a clear need for them. Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. (This is HMAC-SHA, not plain SHA. Also, there is a huge difference in the ability to resist an offline attack vs. the ability to resist an online attack.) Avoiding these ciphersuites also allows us to sidestep the possibility of performance regressions from enabling TLS 1.2.

Put RSA key exchange, RC4, HMAC-MD5, 3DES, DSS (non-ECC DSA) on the path to retirement.

As explained above, we should discourage RSA key exchange because ephemeral key exchange has clear security and privacy benefits. “On the Security of RC4 in TLS” explains why browsers need to stop supporting RC4 as soon as is practical. Although HMAC-MD5 is still considered secure, there is really no reason for anybody to use it anymore, especially considering that there are no HMAC-MD5 ciphersuites that support ephemeral key exchange. 3DES has a very poor security-to-performance ratio. DSS certificates are basically unheard of on the internet, and have been largely superseded for US Government use by ECDSA certificates, so it is not worth trying to add ECDHE, AES-GCM, or AES-CBC-SHA2 ciphersuites for use with DSS certificates.

All of the ciphersuites that use these deprecated algorithms are put at the end of the list, prioritized according to the above criteria. An argument could be made for putting the TLS_ECDHE_*_WITH_RC4_128_SHA ciphersuites ahead of the TLS_DHE_* ciphersuites, given that there are many servers known to use weak DHE keys and that RC4 attacks are not yet practical. On the other hand, a site that uses a strong DHE key and that follows the suggestion in the TLS specifications should not be victimized by future improvements of the RC4 attacks. Also, browsers should implement coping mechanisms for weak DHE keys, such as redoing the handshake with the TLS_DHE_* ciphersuites disabled when the server's DHE key is weak; this can actually be done in a secure manner, unlike TLS version intolerance feedback.

Future work: Ephemeral certificates.

When ephemeral key exchange is used, the server's ephemeral key exchange parameters are signed by the server's end-entity certificate, which is in turn signed by an intermediate CA certificate, which is in turn signed by the root CA's certificate. The signature of the ephemeral key exchange parameters covers the nonces used in the TLS handshake, so the server must do that signing for every full handshake and the client must verify that signature in every full handshake.

If the intermediate certificate that signs the end-entity certificate is under the control of the website, then there is potentially a more efficient way of doing ephemeral key exchange by using ephemeral certificates. In this scheme, the website's private certificate authority would regularly issue a new ECDH certificate with new ECDH parameters and a very short validity period (a period of minutes or hours). Effectively, the intermediate CA's single signature on the end-entity certificate authenticates both the key exchange parameters and the end-entity certificate. If the server reuses these certificates for more than one handshake, then it can save one signing operation per handshake. Similarly, the client would save one signature verification operation per handshake.

Most, if not all, server-side software would require the ECDH private key for the end-entity certificate to be written to permanent storage. This increases the risk of the key being compromised. Further, most, if not all, TLS stacks lack the ability to automatically issue and rotate end-entity certificates. Accordingly, the safe assumption is that all ECDH certificates are not ephemeral. Because of the potential efficiency gains, it worth experimenting with adding proper support for managing ephemeral ECDH certificates to servers' TLS stacks. If those experiments are successful then browsers should consider adding some TLS_ECDH_* ciphersuites. If we were to add (back) support for ECDH key exchange, we would need to support at least one additional ciphersuite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256.

Future work: New high-performance side-channel-free ciphersuites.

This document deprecates all non-AES ciphersuites that browsers typically support. We should have an alternative algorithm to fall back to in the event that a serious problem is found with AES. Further, we should have an authenticated encryption algorithm that offers high performance on all platforms (particularly ARM and x86) with a constant-time implementation. It has been suggested that Salsa20 with UMAC or VMAC or Poly1305 may check all the right boxes.

If we were to add such ciphersuites, we would need at least two variants: TLS_ECDHE_ECDSA_WITH_* and TLS_ECDHE_RSA_WITH_*. If we add support for ephemeral ECDH certificates, then we would need two more variants: TLS_ECDH_ECDSA_WITH_* and TLS_ECDH_RSA_WITH_*.

Future work: A comprehensive profile for browsers' use of TLS.

Certificate chain building and verification, including revocation checking, is the area where more consistency between implementations is most critical. A separate proposal that attempts to address this is forthcoming.

If browser makers agree that trying to reduce fingerprinting via differences in TLS handshaking behavior is a goal, then we can extend this set of recommendations into a full profile of standardized behaviors. This would include, for example, specifying which TLS extensions to send, in what order to send TLS extensions, and what the form of each extension would be.

Even if we do not agree that protecting against fingerprinting is a goal, then it is still useful to standardize other aspects of browser's TLS usage. For example, it is useful for improving interoperability to agree on which version number should appear in the record layer of the ClientHello message and in the premaster secret. See NSS bug 774547. and NSS bug 783448.

Which ciphersuites would be added/removed from each browser, if they were to implement this proposal?