[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                        J. Mattsson
Internet-Draft                                                  Ericsson
Intended status: Informational                              July 4, 2014
Expires: January 5, 2015


            Overview and Analysis of Overhead Caused by TLS
                   draft-mattsson-uta-tls-overhead-00

Abstract

   A common argument against the use of TLS is that it adds overhead.
   In this document we illustrate in detail how much (or little)
   processing, latency, and traffic overhead TLS adds.  Transition to
   more secure cipher suites (TLS 1.2 with AES-GCM or ChaCha20-Poly1305)
   actually reduces both traffic and processing overhead.  AES-GCM
   combines security, low traffic overhead, and great performance on
   modern hardware.  On platforms without hardware support for AES-GCM,
   ChaCha20-Poly1305 gives the same benefits.  For everything but very
   short connections, TLS is not inducing any major traffic overhead
   (nor CPU or memory overhead).

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 January 5, 2015.

Copyright Notice

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



Mattsson                 Expires January 5, 2015                [Page 1]


Internet-Draft                TLS Overhead                     July 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  TLS Handshake . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Latency Overhead  . . . . . . . . . . . . . . . . . . . .   3
   3.  TLS Record Layer  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Ciphers in Use  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Traffic Overhead  . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Processing Overhead . . . . . . . . . . . . . . . . . . .   6
       3.3.1.  Modern x86 Processors . . . . . . . . . . . . . . . .   6
       3.3.2.  Software  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The overhead from TLS can be divided into several different aspects:

   o  Traffic overhead from TLS handshake

   o  Latency overhead from TLS handshake

   o  Traffic overhead from TLS record layer

   o  Processing overhead from TLS handshake

   o  Processing overhead from TLS record layer

   But in many scenarios, TLS does not add much overhead at all, and
   moving to more secure cipher suites actually reduces both traffic and
   processing overhead.

2.  TLS Handshake

   The TLS handshake typically adds 4-7 kB of traffic overhead.  TLS
   compression reduces traffic overhead, but has negative security
   implications and should be turned off [I-D.ietf-uta-tls-bcp].

   Looking at the certificates, a move from 1024 to 2048 bit RSA keys
   increases traffic and processing overhead but is needed for security



Mattsson                 Expires January 5, 2015                [Page 2]


Internet-Draft                TLS Overhead                     July 2014


   reasons.  Certificates with 1024 bit RSA keys should be phased out as
   they only gives 80 bit security.  NIST recommendation is to stop
   using algorithms giving 80 bit security no later that 2010
   [KeyLength].  A move from SHA-1 to SHA-256 adds processing overhead
   but is needed for security reasons.  SHA-1 should not be used anymore
   for digital signatures (e.g. in certificates) as it gives less than
   80 bit security.  To summarize, SHA-2 certificates with at least 2048
   bit RSA keys should be used.

2.1.  Latency Overhead

   In TLS 1.2 [RFC5246] and earlier versions, the initial handshake
   takes 2 round-trips and session resumption takes 1 round-trip.  In
   TLS 1.3 [I-D.ietf-tls-tls13] the target is 1 round-trip for the
   initial round-trip and 0 round-trips for session resumption.  Because
   of the emphasis on reducing latency (instead of only security), TLS
   1.3 is expected to have much faster deployment than earlier versions.

3.  TLS Record Layer

   Some of the most commonly used ciphersuites have security weaknesses.
   Encryption algorithms such as RC4 and the CBC modes (e.g.  AES and
   3DES_EDE) have security weaknesses, and the hash functions SHA-1 and
   MD5 (but not the HMAC constructions used in TLS record layer) also
   have security weaknesses.

   More recent ciphersuites using AES-GCM and CHACHA20_POLY1305 have no
   known security weaknesses, but AES-GCM, CHACHA20_POLY1305 and other
   AEAD suites requires TLS 1.2 [RFC5246].  CHACHA20_POLY1305 is
   currently only an Internet draft but is still used in practice as it
   is very fast in software [I-D.agl-tls-chacha20poly1305].  AES-GCM is
   the current IETF recommendation (Internet Draft) as part of
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [I-D.ietf-uta-tls-bcp].

3.1.  Ciphers in Use

   In data from 2013 [Gueron], AES-CBC, RC4, and HMAC-SHA1 dominates,
   these ciphersuites all have security weaknesses.  The more secure
   options AES-GCM and CHACHA20_POLY1305 would show up in more recent
   measurements











Mattsson                 Expires January 5, 2015                [Page 3]


Internet-Draft                TLS Overhead                     July 2014


      Cipher                                               Usage
      ----------------------------------------------------------
      AES256-SHA-1                                          44 %
      AES128-SHA-1                                          36 %
      RC4-MD5                                               15 %
      RC4-SHA-1                                              3 %
      DES-CBC3-SHA-1                                         2 %
      ----------------------------------------------------------

                  Table 1: Ciphers in Use (Gueron, 2013)

3.2.  Traffic Overhead

   The traffic overhead depends on the ciphersuite used, and comes in
   three different forms, the TLS record layer header, encryption
   algorithm padding, and the MAC tag, which comes from either the
   authentication algoritm (SHA-1, MD5) or an AEAD algorithm (GCM,
   Poly1305).  If the encryption algorithm padding and the MAC tag is
   called "TLS Trailer", a packet protected by TLS looks like this:

         +------+-------+--------------+-------+---------------+
         |  IP  |  TCP  |  TLS Header  |  ...  |  TLS Trailer  |
         +------+-------+--------------+-------+---------------+

                 Figure 1: Format of TLS protected packet

   The size of the TLS trailer is fixed (5 bytes), while the size of the
   TLS Trailer is either fixed or variable (variable for the
   ciphersuites that uses padding, e.g. the CBC ones).  The per-packet
   overhead for the most important ciphersuites are shown below:

      ----------------------------------------------------------
      Per-packet overhead             25-40 bytes (average 32.5)
         TLS header                                      5 bytes
         TLS trailer                                 20-35 bytes
            HMAC-SHA-1                                  20 bytes
            CBC padding                               0-15 bytes
      ----------------------------------------------------------

                     AES_128_CBC_SHA, AES_256_CBC_SHA











Mattsson                 Expires January 5, 2015                [Page 4]


Internet-Draft                TLS Overhead                     July 2014


      ----------------------------------------------------------
      Per-packet overhead             25-32 bytes (average 28.5)
         TLS header                                      5 bytes
         TLS trailer                                 20-27 bytes
            HMAC-SHA-1                                  20 bytes
            CBC padding                                0-7 bytes
      ----------------------------------------------------------

                             3DES_EDE_CBC_SHA

      ----------------------------------------------------------
      Per-packet overhead                               25 bytes
         TLS header                                      5 bytes
         TLS trailer                                    20 bytes
            HMAC-SHA-1                                  20 bytes
      ----------------------------------------------------------

                                RC4_128_SHA

      ----------------------------------------------------------
      Per-packet overhead                               21 bytes
         TLS header                                      5 bytes
         TLS trailer                                    16 bytes
            HMAC-MD5                                    16 bytes
      ----------------------------------------------------------

                                RC4_128_MD5

      ----------------------------------------------------------
      Per-packet overhead                               21 bytes
         TLS header                                      5 bytes
         TLS trailer                                    16 bytes
            HMAC-MD5                                    16 bytes
      ----------------------------------------------------------

                         AES_128_GCM, AES_256_GCM

      ----------------------------------------------------------
      Per-packet overhead                               21 bytes
         TLS header                                      5 bytes
         TLS trailer                                    16 bytes
            HMAC-MD5                                    16 bytes
      ----------------------------------------------------------

                             CHACHA20_POLY1305

   As can be seen from the tables above, there is a correlation between
   better security and low traffic overhead.  Going from AES_CBC_SHA



Mattsson                 Expires January 5, 2015                [Page 5]


Internet-Draft                TLS Overhead                     July 2014


   (mandatory to implement in TLS 1.1 [RFC4346] and 1.2 [RFC5246]) to
   one of the more secure options AES_GCM (current IETF recommendation)
   or CHACHA20_POLY1305 reduces record layer traffic overhead with 35 %.

3.3.  Processing Overhead

   Just as with traffic overhead, there is a correlation between better
   security and low processing overhead.  Going from AES_CBC_SHA
   (mandatory to implement in TLS 1.1. and 1.2) to the more secure
   option AES-GCM reduces processing overhead on a Core-i7-3770
   processor with 57 %.

3.3.1.  Modern x86 Processors

   On processors with hardware support for AES and CLMUL (all modern x86
   CPUs).  AES_GCM is much faster that RC4_SHA, AES_CBC_SHA, or
   CHACHA20_POLY1305.  Data from (Gueron, 2013) [Gueron].

      Cipher                                 Speed (cycles/byte)
      ----------------------------------------------------------
      AES-CBC + HMAC-SHA256 (serial)                       15.57
      RC4 + HMAC-SHA1                                       8.97
      AES-CBC + HMAC-SHA1                                   5.59
      AES-GCM                                               2.42
      ----------------------------------------------------------

                      Table 2: Speed on Core-i7-3770

3.3.2.  Software

   Without hardware support for AES and CLMUL, CHACHA20 with POLY1305 is
   much faster that AES_GCM (and AES-CBC).  Data from [Software].

      Chip                   AES-128-GCM     ChaCha20-Poly1305
      --------------------------------------------------------
      OMAP 4460               24.1 MB/s              75.3 MB/s
      Snapdragon S4 Pro       41.5 MB/s             130.9 MB/s
      Sandy Bridge Xeon      900.0 MB/s             500.0 MB/s
      --------------------------------------------------------

    Table 3: Speed with and without hardware support for AES and CLMUL

   Several companies have deployed ChaCha20_Poly1305 to get optimal
   performance (and security) on platforms without AES and CLMUL
   hardware support.  This may have less significance in the future if
   mobile CPUs implement hardware support for AES-GCM.





Mattsson                 Expires January 5, 2015                [Page 6]


Internet-Draft                TLS Overhead                     July 2014


4.  Conclusions

   Transition to more secure cipher suites (TLS 1.2 with AES-GCM or
   ChaCha20-Poly1305) actually reduces both traffic and processing
   overhead.  Going from AES_CBC_SHA (mandatory to implement in TLS 1.1.
   and 1.2) to AES_GCM (current IETF recommendation) or
   CHACHA20_POLY1305 reduces record layer traffic overhead with 35 %,
   and record layer processing overhead with even more.  AES-GCM
   combines security, low traffic overhead, and great performance on
   modern x86 hardware.  On platforms without hardware support for AES-
   GCM, ChaCha20-Poly1305 gives the same benefits.

   Looking at the certificates, a transition to SHA-2 certificates with
   RSA-2048 keys increases TLS handshake traffic and processing overhead
   but is needed for security reasons.

   For everything but very short connections, TLS is not inducing any
   major traffic overhead (nor CPU or memory overhead).  Server people
   from Google Gmail has stated that "TLS accounts for less than 1% of
   the CPU load, less than 10 KB of memory per connection and less than
   2% of network overhead".  Main impact of TLS is increased latency,
   this can by reduced by using session resumption, cache information
   closer to end users, or waiting for TLS 1.3.

5.  Security Considerations

   The whole document is about increasing the use of TLS and secure
   ciphersuites by showing that TLS is many cases does not add much
   overhead, and that there for many types of overhead is a correlation
   between better security and low overhead.

6.  References

   [Gueron]   Shay Gueron, "AES-GCM for Efficient Authenticated
              Encryption - Ending the Reign of HMAC-SHA-1?",
              <https://crypto.stanford.edu/RealWorldCrypto/slides/
              gueron.pdf>.

   [I-D.agl-tls-chacha20poly1305]
              Langley, A. and W. Chang, "ChaCha20 and Poly1305 based
              Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04
              (work in progress), November 2013.

   [I-D.ietf-tls-tls13]
              Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-01 (work
              in progress), April 2014.




Mattsson                 Expires January 5, 2015                [Page 7]


Internet-Draft                TLS Overhead                     July 2014


   [I-D.ietf-uta-tls-bcp]
              Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of TLS and DTLS", draft-
              ietf-uta-tls-bcp-01 (work in progress), June 2014.

   [KeyLength]
              BlueKrypt, "Cryptographic Key Length Recommendation",
              <http://www.keylength.com/>.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [Software]
              ImperialViolet, "TLS Symmetric Crypto",
              <https://www.imperialviolet.org/2014/02/27/
              tlssymmetriccrypto.html>.

Author's Address

   John Mattsson
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 43 501
   Email: john.mattsson@ericsson.com






















Mattsson                 Expires January 5, 2015                [Page 8]