Re: [Secdispatch] Power measurements

Carsten Bormann <cabo@tzi.org> Wed, 06 March 2019 13:18 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD36130EC6 for <secdispatch@ietfa.amsl.com>; Wed, 6 Mar 2019 05:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2jc-I8o4LFB for <secdispatch@ietfa.amsl.com>; Wed, 6 Mar 2019 05:18:02 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8734E1292F1 for <secdispatch@ietf.org>; Wed, 6 Mar 2019 05:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x26DHpN8004781; Wed, 6 Mar 2019 14:17:56 +0100 (CET)
Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44DvSv3sXtz1Br6; Wed, 6 Mar 2019 14:17:51 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <VI1PR0801MB2112E89F6643346C1924EFA7FA730@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Date: Wed, 06 Mar 2019 14:17:50 +0100
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>
X-Mao-Original-Outgoing-Id: 573571068.686396-1371983cece476cef85e10e01da8de07
Content-Transfer-Encoding: quoted-printable
Message-Id: <61E7A758-E9B3-4766-9267-A985C243FE29@tzi.org>
References: <VI1PR0801MB2112E89F6643346C1924EFA7FA730@VI1PR0801MB2112.eurprd08.prod.outlook.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE>
Subject: Re: [Secdispatch] Power measurements
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 13:18:04 -0000

On Mar 6, 2019, at 13:21, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
> Hi all, 
>  
> Yesterday a few measurements of 3GPP & LoRAWAN power measurements were presented. I asked whether the provided data are estimates based on some model or whether they are the results of some measurements.

Imagine the estimates were made on the back of an envelope, informed by some measurements but not by measuring exactly what was postulated.
I understand we are all curious (I certainly am), but for the purposes of secdispatch:
How would it help to know the detailed technique that was employed?

The design technique that led to EDHOC could be termed ALARA (as low as reasonably achievable): If there is an opportunity to reduce the cost, we are happy if that can be used.
Of course, we need to clarify what is “reasonable” (e.g., losing some security was “reasonable” for TLS 1.3 0RTT because it was believed that property can be explained).
Data from the various deployment environments can help us decide whether we are there yet.
But that decision is a bit like the influence of patents: Every one of us has to make it; there won’t be consensus about the criteria, and trying to generate a consensus document about that would be so ludricous that it would be obvious why people want that.

It is good that work on making (D)TLS more compact continues.  It started with DTLS 1.3, and once that is done, we will immediately be able to take advantage of that for CoAP.  There is also the ATLAS work.  Work on what I’ll call cutlass (“cTLS”) is just starting, and I’m looking forward to an even more concise version of (D)TLS.  But it is not a given that what is “reasonable” for EDHOC will turn out “reasonable” for the TLS brand, so I’m not holding by breath.  And I don’t have to, because EDHOC is there.  

Grüße, Carsten