Re: [Iot-directorate] Iotdir early review of draft-camwinget-tls-ts13-macciphersuites-06

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Hi Michael,
Thanks for the review.  Adrian also provided feedback to the use cases as we (the authors) will work towards tightening them up
Or clarifying them.....and correct that (at least for me) the most compelling one is the blackbox auditability.  The others are also there
as some of the not so older systems do not have AES but yes to SHA-2.  I believe the authentication could be done at a software stack
as that is not done as frequently.

Warm regards,  Nancy

On 8/8/20, 7:01 PM, "Iot-directorate on behalf of Michael Richardson via Datatracker" <[e-mail] on behalf of [e-mail]> wrote:

    Reviewer: Michael Richardson
    Review result: Ready
    
    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.
    
    
    
    
    
    -- 
    Iot-directorate mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/iot-directorate