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: > 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.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 > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
