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