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

From: Michael Richardson via Datatracker <[email-masked]>
Date: Sat, 08 Aug 2020 19:00:53 -0700

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.

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Sun, 9 Aug 2020 06:52:52 -0700

Michael,

Very many thanks for this. It helps me a lot.

Best,
Adrian

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 9 Aug 2020 14:10:11 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    

    -- 
    Iot-directorate mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iot-directorate

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Aug 2020 16:35:34 -0400

I can believe that many systems would find software based SHA-1 (or MD5!) significantly
faster than software-based 3DES.
I suspect that there is a "genetic memory" of this fact, which has persisted
as "hashes faster than encryption"

> The others are also there as some of the not so older systems do not have
> AES but yes to SHA-2.

I believe that there are people who have decided to implement SHA-2, and have
decided not to implement AES.  Perhaps there are compelling code space
reasons for this, but I don't find the performance/latency reasons compelling.

But, we agree that blackbox auditability *is* compelling, and therefore the
draft should go forward.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jack Visoky <[email-masked]>
Date: Mon, 10 Aug 2020 19:07:08 +0000

Hi Michael,

Thanks for the feedback, your comments are well founded, however I will say that in Industrial Automation we have found places where the performance of just SHA256 (in hardware) to be more performant than either SHA256 + AES or AES GCM.  The differences are not great, but compelling enough that for some use cases they make a difference.  We always run into cases where people want to run communications as fast as possible but in a very cost sensitive hardware build (cyclic motion communication is the most common case of this).  As Nancy said, we will be making some updates to these use cases that (we hope) clarify them further.

Thanks,

--Jack

-----Original Message-----
From: Nancy Cam-Winget (ncamwing) <[email-masked]> 
Sent: Sunday, August 9, 2020 10:10 AM
To: Michael Richardson <[email-masked]>; [email-masked]
Cc: [email-masked]; Jack Visoky <[email-masked]>
Subject: EXTERNAL: Re: [Iot-directorate] Iotdir early review of draft-camwinget-tls-ts13-macciphersuites-06

[Use caution with links & attachments]

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