idnits 2.17.1 draft-mattsson-uta-tls-overhead-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Padding' is mentioned on line 166, but not defined == Unused Reference: 'Gueron' is defined on line 345, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-02 == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-06 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft Ericsson 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 Overview and Analysis of Overhead Caused by TLS 8 draft-mattsson-uta-tls-overhead-01 10 Abstract 12 A common argument against the use of TLS is that it adds overhead. 13 In this document we illustrate in detail how much (or little) 14 processing, latency, and traffic overhead TLS adds. Transition to 15 more secure cipher suites (TLS 1.2 with AES-GCM or ChaCha20-Poly1305) 16 actually reduces both traffic and processing overhead. AES-GCM 17 combines security, low traffic overhead, and great performance on 18 modern hardware. On platforms without hardware support for AES-GCM, 19 ChaCha20-Poly1305 gives the same benefits. For everything but very 20 short connections, TLS is not inducing any major traffic overhead 21 (nor CPU or memory overhead). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 30, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2.1. Latency Overhead . . . . . . . . . . . . . . . . . . . . 3 60 3. TLS Record Layer . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Ciphers in Use . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Traffic Overhead . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Processing Overhead . . . . . . . . . . . . . . . . . . . 6 64 3.3.1. Modern x86 Processors . . . . . . . . . . . . . . . . 7 65 3.3.2. Software . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The overhead from TLS can be divided into several different aspects: 76 o Traffic overhead from TLS handshake 78 o Latency overhead from TLS handshake 80 o Traffic overhead from TLS record layer 82 o Processing overhead from TLS handshake 84 o Processing overhead from TLS record layer 86 But in many scenarios, TLS does not add much overhead at all, and 87 moving to more secure cipher suites actually reduces both traffic and 88 processing overhead. 90 2. TLS Handshake 92 The TLS handshake typically adds 4-7 kB of traffic overhead. TLS 93 compression reduces traffic overhead, but has negative security 94 implications and should be turned off [I-D.ietf-uta-tls-bcp]. 96 Looking at the certificates, a move from 1024 to 2048 bit RSA keys 97 increases traffic and processing overhead but is needed for security 98 reasons. Certificates with 1024 bit RSA keys should be phased out as 99 they only gives 80 bit security. NIST recommendation is to stop 100 using algorithms giving 80 bit security no later that 2010 101 [KeyLength]. A move from SHA-1 to SHA-256 adds processing overhead 102 but is needed for security reasons. SHA-1 should not be used anymore 103 for digital signatures (e.g. in certificates) as it gives less than 104 80 bit security. To summarize, SHA-2 certificates with at least 2048 105 bit RSA keys should be used. 107 2.1. Latency Overhead 109 In TLS 1.2 [RFC5246] and earlier versions, the initial handshake 110 takes 2 round-trips and session resumption takes 1 round-trip. In 111 TLS 1.3 [I-D.ietf-tls-tls13] the target is 1 round-trip for the 112 initial round-trip and 0 round-trips for session resumption. Because 113 of the emphasis on reducing latency (instead of only security), TLS 114 1.3 is expected to have much faster deployment than earlier versions. 116 3. TLS Record Layer 118 Some of the most commonly used ciphersuites have security weaknesses. 119 Encryption algorithms such as RC4 and the CBC modes (e.g. AES and 120 3DES_EDE) have security weaknesses, and the hash functions SHA-1 and 121 MD5 (but not the HMAC constructions used in TLS record layer) also 122 have security weaknesses. 124 More recent ciphersuites using AES-GCM and CHACHA20_POLY1305 have no 125 known security weaknesses, but AES-GCM, CHACHA20_POLY1305 and other 126 AEAD suites requires TLS 1.2 [RFC5246]. CHACHA20_POLY1305 is 127 currently only an Internet draft but is still used in practice as it 128 is very fast in software [I-D.agl-tls-chacha20poly1305]. AES-GCM is 129 the current IETF recommendation (Internet Draft) as part of 130 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [I-D.ietf-uta-tls-bcp]. 132 3.1. Ciphers in Use 134 These data is included as to motivate which algorithms to cover as 135 well as showing that new secure ciphersuites are gaining signifiacant 136 usage. In data from July 2014 [ICSI], AES-CBC, RC4, and HMAC-SHA1 137 dominates, these ciphersuites all have security weaknesses. The NULL 138 cipher does not provide any confidentiality at all. The more secure 139 options AES-GCM and ChaCha20-Poly1305 are starting to showing 140 significant usage. 3DES_EDE_CBC_SHA is includes as it is mandatory to 141 implement in TLS 1.0. 143 Algorithm Usage 144 ---------------------------------------------------------- 145 AES_128_CBC_SHA 29.1 % 146 RC4_128_SHA 17.4 % 147 AES_128_GCM 14.7 % 148 AES_256_CBC_SHA 14.0 % 149 NULL_SHA 9.8 % 150 RC4_128_MD5 8.3 % 151 CHACHA20_POLY1305 1.4 % 152 3DES_EDE_CBC_SHA < 5.6 % 153 ---------------------------------------------------------- 155 Table 1: Ciphers in Use (ICSI, July 2014) 157 3.2. Traffic Overhead 159 The traffic overhead comes in different forms: the TLS record layer 160 header, Explicit IV/Nonce, MAC tag, and encryption algorithm padding. 161 Figure 1 illustrates the packet format for a TLS protected package 162 where [ ] indicates fields where usage depends on the TLS version and 163 the ciphersuite used. 165 +----+-----+------------+------------+--------------+-----+-----------+ 166 | IP | TCP | TLS Header | [IV/Nonce] | Enc. Content | MAC | [Padding] | 167 +----+-----+------------+------------+--------------+-----+-----------+ 169 Figure 1: Format of TLS protected packet 171 The size of the TLS header is fixed (5 bytes). The size of the IV/ 172 Nonce depends on the TLS version and the ciphersuite used. Explicit 173 IV is used by CBC ciphersuites in TLS 1.1 and TLS 1.2, but not TLS 174 1.0. Explicit Nonce is used by AEAD algorithms. The size of the MAC 175 tag depends on the ciphersuite used, it is either a separate field 176 (non-AEAD algorithms like SHA-1, MD5) or included in the ciphertext 177 (AEAD algorithms like GCM, Poly1305). Padding is used by CBC 178 ciphersuites. 180 The per-packet overhead for the most important ciphersuites are shown 181 below (the values are all theoretical and the averages are calculates 182 over a uniform distribution). For comparision, the TCP/IP overhead 183 for IPv4 and IPv6 are 52 and 72 bytes, respectively. 185 ----------------------------------------------------------------- 186 AES_128_CBC_SHA, AES_256_CBC_SHA 187 ----------------------------------------------------------------- 188 Per-packet overhead (TLS 1.0) 26-41 bytes (avg. 33.5) 189 TLS header 5 bytes 190 HMAC-SHA-1 20 bytes 191 CBC padding 1-16 bytes 193 Per-packet overhead (TLS 1.1, 1.2) 42-57 bytes (avg. 49.5) 194 TLS header 5 bytes 195 Explicit IV 16 bytes 196 HMAC-SHA-1 20 bytes 197 CBC padding 1-16 bytes 198 ----------------------------------------------------------------- 200 ----------------------------------------------------------------- 201 3DES_EDE_CBC_SHA 202 ----------------------------------------------------------------- 203 Per-packet overhead (TLS 1.0) 26-33 bytes (avg. 29.5) 204 TLS header 5 bytes 205 HMAC-SHA-1 20 bytes 206 CBC padding 1-8 bytes 208 Per-packet overhead (TLS 1.1, 1.2) 34-41 bytes (avg. 37.5) 209 TLS header 5 bytes 210 Explicit IV 8 bytes 211 HMAC-SHA-1 20 bytes 212 CBC padding 1-8 bytes 213 ----------------------------------------------------------------- 215 ----------------------------------------------------------------- 216 RC4_128_SHA, NULL_SHA 217 ----------------------------------------------------------------- 218 Per-packet overhead (TLS 1.0, 1.1, 1.2) 25 bytes 219 TLS header 5 bytes 220 HMAC-SHA-1 20 bytes 221 ----------------------------------------------------------------- 222 ----------------------------------------------------------------- 223 RC4_128_MD5 224 ----------------------------------------------------------------- 225 Per-packet overhead (TLS 1.0, 1.1, 1.2) 21 bytes 226 TLS header 5 bytes 227 HMAC-MD5 16 bytes 228 ----------------------------------------------------------------- 230 ----------------------------------------------------------------- 231 AES_128_GCM, AES_256_GCM 232 ----------------------------------------------------------------- 233 Per-packet overhead (TLS 1.0, 1.1, 1.2) 29 bytes 234 TLS header 5 bytes 235 Explicit Nonce 8 bytes 236 GMAC 16 bytes 237 ----------------------------------------------------------------- 239 ----------------------------------------------------------------- 240 CHACHA20_POLY1305 241 ----------------------------------------------------------------- 242 Per-packet overhead (TLS 1.0, 1.1, 1.2) 29 bytes 243 TLS header 5 bytes 244 Explicit Nonce 8 bytes 245 Poly1305 16 bytes 246 ----------------------------------------------------------------- 248 As can be seen from the tables above, there is a correlation between 249 better security and low traffic overhead. Going from TLS 1.1 250 [RFC4346] with AES_CBC_SHA (mandatory to implement in TLS 1.1) to TLS 251 1.2 [RFC5246] with one of the more secure options AES_GCM (current 252 IETF recommendation) or CHACHA20_POLY1305 reduces record layer 253 traffic overhead with 41 %. Going from TLS 1.0 [RFC2246] with 254 AES_CBC_SHA to TLS 1.2 with AES_GCM or CHACHA20_POLY1305 reduces 255 record layer traffic overhead with 14 %. 257 3.3. Processing Overhead 259 Just as with traffic overhead, there is a correlation between better 260 security and low processing overhead. Going from AES_CBC_SHA 261 (mandatory to implement in TLS 1.1. and 1.2) to the more secure 262 option AES-GCM reduces processing overhead on a Core-i7-3770 263 processor with 57 %. Another fact is that the overhead for 264 AES_128_GCM and CHACHA20_POLY1305 is so low, there is no overhead 265 reasons to not use encryption (i.e. NULL_SHA). 267 3.3.1. Modern x86 Processors 269 On modern x86 processors with hardware support for AES (AES-NI) and 270 carry-less multplication (CLMUL), AES_GCM is much faster that 271 RC4_SHA, AES_CBC_SHA, or CHACHA20_POLY1305. Another performance 272 advantage with AES-GCM is that is designed for parallelization. 274 Algorithm Speed 275 ---------------------------------------------------------- 276 AES_128_GCM 1909.1 MB/s 277 CHACHA20_POLY1305 625.2 MB/s 278 AES_128_CBC_SHA 573.7 MB/s 279 AES_256_CBC_SHA 486.6 MB/s 280 RC4_128_MD5 233.9 MB/s 281 ---------------------------------------------------------- 283 Table 2: Speed on 2 GHz Intel Core i7 285 These measuments are not fair to Chacha20-Poly1305, but this does not 286 matter, the important thing is who fast does the algorithms run on 287 current hardwware. 289 3.3.2. Software 291 Without hardware support for AES-GCM, ChaCha20-Poly1305 is much 292 faster that AES-GCM (and AES-CBC). Data from [Software]. 294 Algorithm Speed 295 ---------------------------------------------------------- 296 CHACHA20_POLY1305 130.9 MB/s 297 AES_128_GCM 41.5 MB/s 298 ---------------------------------------------------------- 300 Table 3: Speed on Snapdragon S4 Pro 302 Several companies have deployed ChaCha20-Poly1305 to get better 303 performance (and security) on platforms without AES and CLMUL 304 hardware support. This may have less significance in the future if 305 mobile CPUs implement hardware support for AES-GCM. 307 4. Conclusions 309 Transition to more secure cipher suites (TLS 1.2 with AES-GCM or 310 ChaCha20-Poly1305) actually reduces both traffic and processing 311 overhead. Going from TLS 1.1 with AES_CBC_SHA (mandatory to 312 implement in TLS 1.1) to TLS 1.2 with AES_GCM (current IETF 313 recommendation) or CHACHA20_POLY1305 reduces record layer traffic 314 overhead with 41 %, and record layer processing overhead with even 315 more. AES-GCM combines security, low traffic overhead, and great 316 performance on modern x86 hardware. On platforms without hardware 317 support for AES-GCM, ChaCha20-Poly1305 gives the same benefits. 319 Looking at the certificates, a transition to SHA-2 certificates with 320 RSA-2048 keys increases TLS handshake traffic and processing overhead 321 but is needed for security reasons. 323 For everything but very short connections, TLS is not inducing any 324 major traffic overhead (nor CPU or memory overhead). Server people 325 from Google Gmail has stated that "TLS accounts for less than 1% of 326 the CPU load, less than 10 KB of memory per connection and less than 327 2% of network overhead". Main impact of TLS is increased latency, 328 this can by reduced by using session resumption, cache information 329 closer to end users, or waiting for TLS 1.3. 331 5. Security Considerations 333 The whole document is about increasing the use of TLS and secure 334 ciphersuites by showing that TLS is many cases does not add much 335 overhead, and that there for many types of overhead is a correlation 336 between better security and low overhead. 338 6. Acknowledgements 340 The authors would like to thank Stephen Farrell and Ivan Ristic for 341 their valuable comments and feedback. 343 7. References 345 [Gueron] Shay Gueron, "AES-GCM for Efficient Authenticated 346 Encryption - Ending the Reign of HMAC-SHA-1?", 347 . 350 [I-D.agl-tls-chacha20poly1305] 351 Langley, A. and W. Chang, "ChaCha20 and Poly1305 based 352 Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 353 (work in progress), November 2013. 355 [I-D.ietf-tls-tls13] 356 Dierks, T. and E. Rescorla, "The Transport Layer Security 357 (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-02 (work 358 in progress), July 2014. 360 [I-D.ietf-uta-tls-bcp] 361 Sheffer, Y., Holz, R., and P. Saint-Andre, 362 "Recommendations for Secure Use of TLS and DTLS", draft- 363 ietf-uta-tls-bcp-06 (work in progress), October 2014. 365 [ICSI] ICSI, "The ICSI Certificate Notary", 366 . 368 [KeyLength] 369 BlueKrypt, "Cryptographic Key Length Recommendation", 370 . 372 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 373 RFC 2246, January 1999. 375 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 376 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 378 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 379 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 381 [Software] 382 ImperialViolet, "TLS Symmetric Crypto", 383 . 386 Author's Address 388 John Mattsson 389 Ericsson AB 390 SE-164 80 Stockholm 391 Sweden 393 Phone: +46 10 71 43 501 394 Email: john.mattsson@ericsson.com