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 On 05/07/14 13:14, "Stephen Farrell" <[email protected]> wrote: > >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?) Good point, that should be mentioned as both traffic and latency overhead. I don’t think it’s included. >- 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.) 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… >- 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 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. >- 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. 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. >- 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. Good idea, I’ll ask for that. > >Cheers, >S. > > > >On 04/07/14 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. >> >> 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 >> _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
