Reviewer: Michael Richardson Review result: Ready with Nits Document: draft-camwinget-tls-ts13-macciphersuites-06 I have reviewed this document. I found it clear and well written. I reviewed the discussion in the TLS WG list at: https://mailarchive.ietf.org/arch/msg/tls/0oy4wY4xiB1tASCBDWczh2xTVMM/ I found the discussion in the TLS list as to why the TLS WG should not adopt it compelling, and I understand and agree with the reasons to go via the ISE. I do not feel that this is a run-around the WG. I did not find the three initial use cases at all compelling :-( SHA256, implemented in software, is not particularly faster than AES. See, for instance: https://cryptopp.com/benchmarks.html where we see ~100 MiB/s {O(10^2)} for most algorithms on "big CPU" (with some exceptions) I suspect they are all bound by memory I/O speeds, not details of the algorithm. I could not see an AEAD mode bench tested on that page. On smaller CPUs, the difference MIGHT be more compelling, but on the smaller such CPUs, there is usually AES acceleration, which would make use of an hardware acclerated AES based AEAD algorithm likely better than SHA256. Of course, there is probably some devices, built without any security in mind, which lack even that. I question whether or not they will be able to do reasonable authentication of the TLS end points (the RSA or ECDSA operations). The use which I *DID* find compelling was in the fourth case, and I suspect that it covers many of the other cases. Furthermore, requirements for providing blackbox recording of the safety related network traffic can only be fulfilled through using integrity only ciphers, to be able to provide the safety related commands to a third party, which is responsible for the analysis after an accident. I found this compelling, as it has nothing at all to do with relative speeds, or perceived latencies, but on audit trails.