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

Michael Richardson via Datatracker <noreply@ietf.org> Sun, 09 August 2020 02:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B337D3A0B68; Sat, 8 Aug 2020 19:00:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Michael Richardson via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-camwinget-tls-ts13-macciphersuites.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159693845367.4048.18288256104777981676@ietfa.amsl.com>
Reply-To: Michael Richardson <mcr+ietf@sandelman.ca>
Date: Sat, 08 Aug 2020 19:00:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/EcGwiDMXxnqUYLnh03dDVuq_IhQ>
Subject: [Iot-directorate] Iotdir early review of draft-camwinget-tls-ts13-macciphersuites-06
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 02:00:54 -0000

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.