Subject: [Uta] FW: New Version Notification for draft-mattsson-uta-tls-overhead-00.txt

From: John Mattsson <[email-masked]>
Date: Fri, 4 Jul 2014 22:48:39 +0000

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.

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-masked]" <[email-masked]>
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.txt
>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
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 05 Jul 2014 12:14:42 +0100

Nice! Something like this could be very helpful, thanks.

Some comments ...

- You don't mention OCSP, which in fairness is an issue
  (but do include pinning - is that included in the 4-7kB
  in section 2?)
- More generally section 2 could do with some more detail,
  and being based on some measurement as section 3 is based
  on [Gueron] and [Software] (though better references
  for those would be good too.)
- 3.3.1 and 3.3.2 use different units (cycles/byte and
  MS/s), it'd be good to use one or tell the reader what
  cycles/btye means in terms they are more likely to get
- There's a reasonably liklihood that some text from this
  draft would overlap with or even repeat text from other
  UTA drafts. Normally, we'd want to get rid of such
  overlap, but the audiences for this and those other
  RFCs would be sufficiently different that I think some
  overlaps are probably a good plan in this case.
- Given the recent trend in turning on TLS for MTA-MTA
  traffic, I believe it may be possible to get some good
  numbers from folks who've done that, so asking for that
  would be good.

Cheers,
S.

On 04/07/14 23:48, John Mattsson wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Ivan Ristić <[email-masked]>
Date: Sun, 06 Jul 2014 11:13:38 +0100

> 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.

- 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.

- AEAD GCM suites use a 8-byte per-record nonce instead of the block
cipher IV.

- 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.

- Same comment for CHACHA20_POLY1305, but I don't know the length of the
authentication tag for this suite.

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.

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.

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/

-- 
Ivan

---

From: John Mattsson <[email-masked]>
Date: Mon, 21 Jul 2014 19:46:34 +0000

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

>and there are no additional padding bytes.

Thanks, I forgot the padding length. Fixed.

>used in TLS 1.1+. TLS 1.0 has less overhead, but it's insecure and on

Thanks. Fixed.

>- AEAD GCM suites use a 8-byte per-record nonce instead of the block

Thanks. Fixed.

>because they use their own authentication tag.

Thank. Copy-Paste error. Named it GMAC instead.

>authentication tag for this suite.

Named  it Poly1305, MAC length of 16 bytes is correct.

>overhead in better context.

Done

>significant GCM and CHACHA20_POLY1305 usage.

Thanks for the tips, I was looking for something like this. I’ll use the
ICSI statistics instead.

---

From: John Mattsson <[email-masked]>
Date: Mon, 21 Jul 2014 20:27:36 +0000

Thanks for the comments!

I agree with them all, and I will try to implement as much as possible in
the 01-version, but it depends a little on how good information I can
find/generate.

Any information on the following would be very helpful for a 01-version:

1. More details on handshake traffic overhead and how this differs between
different TLS versions, ciphersuites, extensions, and implementations

2. Overhead details for OCSP.

3. Cycles/byte and memory benchmarks for AES_128_CBC_SHA, RC4_128_SHA,
AES_128_GCM, AES_256_CBC_SHA, NULL_SHA, RC4_128_MD5, CHACHA20_POLY1305,
and 3DES_EDE_CBC_SHA on modern x86 and arm.

4. Good numbers from people using TLS for MTA-MTA.

5. Statistics on number of connections and traffic per connection for real
world TLS usage in different deployments. For long connections the
overhead is very low, but I can imagine that there are cases where TLS
causes a little more overhead, e.g.
  - Webpage with many parallel short connections.
  - Push mail with many serial short connections.

John

>  (but do include pinning - is that included in the 4-7kB

Good point, that should be mentioned as both traffic and latency overhead.
I don’t think it’s included.

>  for those would be good too.)

I agree. I try to add more details in the 01-version. Would be good with
details on how this differs between different TLS versions, ciphersuites,
applications, extensions…

>  cycles/btye means in terms they are more likely to get

I agree. I would prefer cycles/byte as that is independent of frequency.
The measurements should also mention the message sizes used. This was the
best I could find quickly. Anybody knowing good sources?

The best would be to have cycles/byte benchmarks (at least on the latest
x86 and arm CPUs) for all the following:

      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 %
      ----------------------------------------------------------

Some data on memory overhead for the above ciphers would also be good.

>  overlaps are probably a good plan in this case.

That was my though. I think it’s ok as long as any security discussion is
high level. I want to make the point that low overhead and high security
actually goes hand in hand.

>  numbers from folks who've done that, so asking for that

Good idea, I’ll ask for that.