Thank for the corrections and and pointers to better usage statistics!
I have implemented all your comments in the attached version. I will
submit an updated 01 version after the meeting, that version will also
implement most or all of the comments from Stephen.
Cheers,
John
On 06/07/14 12:13, "Ivan Ristić" <[email protected]> wrote:
>On 04/07/2014 23:48, John Mattsson wrote:
>> We have submitted a new draft on TLS overhead. That TLS causes overhead
>>is
>> a common argument regarding TLS (and other security protocols). If TLS
>> adds much overhead has recently been discussed in e.g. GSMA.
>
>I did a similar analysis for my book [1] and extended Vincent Bernat's
>microbenchmarking tool to measure per-record suite overhead [2]. I think
>it's a great idea to shine more light on this topic, given that it's
>very hard to find any information on it.
>
>I looked at your TLS record overhead and they seem a little off:
>
>- The worst case for padding is block size (e.g., 16 bytes for AES-128).
>TLS uses one byte for padding length; if the size of the data is a
>multiple of block size before padding, padding will be a full block
>length. The best case is 1, when only the padding length byte is added
>and there are no additional padding bytes.
Thanks, I forgot the padding length. Fixed.
>
>- You don't have the overhead of the explicit per-record IV, which is
>used in TLS 1.1+. TLS 1.0 has less overhead, but it's insecure and on
>the way out.
Thanks. Fixed.
>
>- AEAD GCM suites use a 8-byte per-record nonce instead of the block
>cipher IV.
Thanks. Fixed.
>
>- The overhead of AEAS GCM suites is correct (16), but the label
>(HMAC-MD5) is incorrect. TLS doesn't apply MAC with authenticated suites
>because they use their own authentication tag.
Thank. Copy-Paste error. Named it GMAC instead.
>
>- Same comment for CHACHA20_POLY1305, but I don't know the length of the
>authentication tag for this suite.
Named it Poly1305, MAC length of 16 bytes is correct.
>
>I also suggest that you also include the TCP/IP overhead for both IPv4
>and IPv6 (52 and 72 bytes, respectively). I think that will put TLS
>overhead in better context.
Done
>
>Another thing, Gueron's statistics seem to come from Akamai. I haven't
>looked them in detail, but I suspect they show how SSL/TLS is used by
>Akamai's platform. While important, their data will be skewed by the
>cipher suites offered by Akamai. What year are the statistics from? Did
>Akamai have TLS 1.2 enabled at that time, and with what suites? Browsers
>added support for TLS 1.3 throught 2013 and I suspect the current
>numbers are pretty different.
>
>I recommend that you have a look at the ICSI notary statistics [3],
>which come from passive analysis on large networks. They already show
>significant GCM and CHACHA20_POLY1305 usage.
Thanks for the tips, I was looking for something like this. I’ll use the
ICSI statistics instead.
>Cheers,
>Ivan
>
>[1] Bulletproof SSL and TLS
> https://www.feistyduck.com/books/bulletproof-ssl-and-tls/
>
>[2] https://github.com/ivanr/ssl-dos
>
>[3] http://notary.icsi.berkeley.edu/
>
>
>> In this document we illustrate that for everything but very short
>> connections, TLS is not inducing any major traffic overhead (nor CPU or
>> memory overhead). Transition to more secure cipher suites (TLS 1.2 with
>> AES-GCM or ChaCha20-Poly1305) actually reduces both traffic and
>>processing
>> overhead.
>>
>> I plan to request time for presentation in Toronto.
>>
>> John Mattsson
>>
>>
>>
>>
>> On 04/07/14 23:32, "[email protected]" <[email protected]>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-mattsson-uta-tls-overhead-00.txt
>>> has been successfully submitted by John Mattsson and posted to the
>>> IETF repository.
>>>
>>> Name: draft-mattsson-uta-tls-overhead
>>> Revision: 00
>>> Title: Overview and Analysis of Overhead Caused by TLS
>>> Document date: 2014-07-04
>>> Group: Individual Submission
>>> Pages: 8
>>> URL:
>>>
>>>http://www.ietf.org/internet-drafts/draft-mattsson-uta-tls-overhead-00.t
>>>xt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-mattsson-uta-tls-overhead/
>>> Htmlized:
>>> http://tools.ietf.org/html/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).
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>
>> _______________________________________________
>> Uta mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>
>
>--
>Ivan
>
>_______________________________________________
>Uta mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/uta
Network Working Group J. Mattsson
Internet-Draft Ericsson
Intended status: Informational July 21, 2014
Expires: January 22, 2015
Overview and Analysis of Overhead Caused by TLS
draft-mattsson-uta-tls-overhead-0.1
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 22, 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 22, 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 . . . . . . . . . . . . . . . . 7
3.3.2. Software . . . . . . . . . . . . . . . . . . . . . . 7
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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].
Mattsson Expires January 22, 2015 [Page 2]
Internet-Draft TLS Overhead July 2014
Looking at the certificates, a move from 1024 to 2048 bit RSA keys
increases traffic and processing overhead but is needed for security
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 July 2014 [ICSI], AES-CBC, RC4, and HMAC-SHA1 dominates,
these ciphersuites all have security weaknesses. The NULL cipher
does not provide any confidentiality at all. The more secure options
AES-GCM and ChaCha20-Poly1305 are starting to showing significant
usage. 3DES_EDE_CBC_SHA is includes as it is mandatory to implement
in TLS 1.0.
Mattsson Expires January 22, 2015 [Page 3]
Internet-Draft TLS Overhead July 2014
Cipher Usage
----------------------------------------------------------
AES_128_CBC_SHA 29.1 %
RC4_128_SHA 17.4 %
AES_128_GCM 14.7 %
AES_256_CBC_SHA 14.0 %
NULL_SHA 9.8 %
RC4_128_MD5 8.3 %
CHACHA20_POLY1305 1.4 %
3DES_EDE_CBC_SHA < 1.2 %
----------------------------------------------------------
Table 1: Ciphers in Use (ICSI, July 2014)
3.2. Traffic Overhead
The traffic overhead comes in different forms: the TLS record layer
header, Explicit IV/Nonce, MAC tag, and encryption algorithm padding.
Figure 1 illustrates the packet format for a TLS protected package
where [ ] indicates fields where usage depends on the TLS version and
the ciphersuite used.
+----+-----+------------+------------+--------------+-----+-----------+
| IP | TCP | TLS Header | [IV/Nonce] | Enc. Content | MAC | [Padding] |
+----+-----+------------+------------+--------------+-----+-----------+
Figure 1: Format of TLS protected packet
The size of the TLS header is fixed (5 bytes). The size of the IV/
Nonce depends on the TLS version and the ciphersuite used. Explicit
IV is used by CBC ciphersuites in TLS 1.1 and TLS 1.2, but not TLS
1.0. Explicit Nonce is used by AEAD algorithms. The size of the MAC
tag depends on the ciphersuite used, it is either a separate field
(non-AEAD algorithms like SHA-1, MD5) or included in the ciphertext
(AEAD algorithms like GCM, Poly1305). Padding is used by CBC
ciphersuites.
The per-packet overhead for the most important ciphersuites are shown
below (the values are all theoretical and the averages are calculates
over a uniform distribution). For comparision, the TCP/IP overhead
for IPv4 and IPv6 are 52 and 72 bytes, respectively.
Mattsson Expires January 22, 2015 [Page 4]
Internet-Draft TLS Overhead July 2014
-----------------------------------------------------------------
AES_128_CBC_SHA, AES_256_CBC_SHA
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0) 26-41 bytes (avg. 33.5)
TLS header 5 bytes
HMAC-SHA-1 20 bytes
CBC padding 1-16 bytes
Per-packet overhead (TLS 1.1, 1.2) 42-57 bytes (avg. 49.5)
TLS header 5 bytes
Explicit IV 16 bytes
HMAC-SHA-1 20 bytes
CBC padding 1-16 bytes
-----------------------------------------------------------------
-----------------------------------------------------------------
3DES_EDE_CBC_SHA
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0) 26-33 bytes (avg. 29.5)
TLS header 5 bytes
HMAC-SHA-1 20 bytes
CBC padding 1-8 bytes
Per-packet overhead (TLS 1.1, 1.2) 34-41 bytes (avg. 37.5)
TLS header 5 bytes
Explicit IV 8 bytes
HMAC-SHA-1 20 bytes
CBC padding 1-8 bytes
-----------------------------------------------------------------
-----------------------------------------------------------------
RC4_128_SHA, NULL_SHA
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0, 1.1, 1.2) 25 bytes
TLS header 5 bytes
HMAC-SHA-1 20 bytes
-----------------------------------------------------------------
Mattsson Expires January 22, 2015 [Page 5]
Internet-Draft TLS Overhead July 2014
-----------------------------------------------------------------
RC4_128_MD5
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0, 1.1, 1.2) 21 bytes
TLS header 5 bytes
HMAC-MD5 16 bytes
-----------------------------------------------------------------
-----------------------------------------------------------------
AES_128_GCM, AES_256_GCM
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0, 1.1, 1.2) 29 bytes
TLS header 5 bytes
Explicit Nonce 8 bytes
GMAC 16 bytes
-----------------------------------------------------------------
-----------------------------------------------------------------
CHACHA20_POLY1305
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0, 1.1, 1.2) 29 bytes
TLS header 5 bytes
Explicit Nonce 8 bytes
Poly1305 16 bytes
-----------------------------------------------------------------
As can be seen from the tables above, there is a correlation between
better security and low traffic overhead. Going from TLS 1.1
[RFC4346] with AES_CBC_SHA (mandatory to implement in TLS 1.1) to TLS
1.2 [RFC5246] with one of the more secure options AES_GCM (current
IETF recommendation) or CHACHA20_POLY1305 reduces record layer
traffic overhead with 41 %. Going from TLS 1.0 [RFC2246] with
AES_CBC_SHA to TLS 1.2 with AES_GCM or CHACHA20_POLY1305 reduces
record layer traffic overhead with 14 %.
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 %. Another fact is that the overhead for
AES_128_GCM and CHACHA20_POLY1305 is so low, there is no overhead
reasons to not use encryption (i.e. NULL_SHA).
Mattsson Expires January 22, 2015 [Page 6]
Internet-Draft TLS Overhead July 2014
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_128_GCM 2.42
AES_128_CBC_SHA 5.59
RC4_128_SHA 8.97
----------------------------------------------------------
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.
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 TLS 1.1 with AES_CBC_SHA (mandatory to
implement in TLS 1.1) to TLS 1.2 with AES_GCM (current IETF
recommendation) or CHACHA20_POLY1305 reduces record layer traffic
overhead with 41 %, 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.
Mattsson Expires January 22, 2015 [Page 7]
Internet-Draft TLS Overhead July 2014
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. Acknowledgements
The authors would like to thank Stephen Farrell and Ivan Ristic for
their valuable comments and feedback.
7. 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-02 (work
in progress), 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.
[ICSI] ICSI, "The ICSI Certificate Notary",
<http://notary.icsi.berkeley.edu/#statistics>.
Mattsson Expires January 22, 2015 [Page 8]
Internet-Draft TLS Overhead July 2014
[KeyLength]
BlueKrypt, "Cryptographic Key Length Recommendation",
<http://www.keylength.com/>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[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: [email protected]
Mattsson Expires January 22, 2015 [Page 9]
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
