[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.
- [Iot-directorate] Iotdir early review of draft-ca… Michael Richardson via Datatracker
- Re: [Iot-directorate] Iotdir early review of draf… RFC ISE (Adrian Farrel)
- Re: [Iot-directorate] Iotdir early review of draf… Nancy Cam-Winget (ncamwing)
- Re: [Iot-directorate] Iotdir early review of draf… Michael Richardson
- Re: [Iot-directorate] EXTERNAL: Re: Iotdir early … Jack Visoky