Early Review of draft-camwinget-tls-ts13-macciphersuites-06
review-camwinget-tls-ts13-macciphersuites-06-iotdir-early-richardson-2020-08-08-00
| Request | Review of | draft-camwinget-tls-ts13-macciphersuites-06 |
|---|---|---|
| Requested revision | 06 (document currently at 12) | |
| Type | Early Review | |
| Team | Internet of Things Directorate (iotdir) | |
| Deadline | 2020-08-30 | |
| Requested | 2020-08-02 | |
| Requested by | Adrian Farrel | |
| Authors | Nancy Cam-Winget , Jack Visoky | |
| I-D last updated | 2020-08-08 | |
| Completed reviews |
Iotdir Early review of -06
by Michael Richardson
(diff)
|
|
| Comments |
This document has been present for publication as an Informational RFC in the Independent Stream. I am particularly interested to know whether the limited security environment proposed by the authors (for very low-end devices and use cases where confidentiality is not a requirement and where the management and auditing tools for these devices rely on the passive capture of the information for auditing purposes only) is realistic and wise (i.e., not dangerous or harmful to the Internet). Publication on the Independent Stream does not require agreement by the IETF community that an idea is good, but it does require some care for the security of users and the Internet. Such care is either expressed through appropriately clear messages in the document, or through non-publication of harmful ideas. |
|
| Assignment | Reviewer | Michael Richardson |
| State | Completed | |
| Request | Early review on draft-camwinget-tls-ts13-macciphersuites by Internet of Things Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/iot-directorate/EcGwiDMXxnqUYLnh03dDVuq_IhQ | |
| Reviewed revision | 06 (document currently at 12) | |
| Result | Ready | |
| Completed | 2020-08-08 |
review-camwinget-tls-ts13-macciphersuites-06-iotdir-early-richardson-2020-08-08-00
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.