Re: [Ace] EST over CoAP: Randomness

Michael StJohns <mstjohns@comcast.net> Sun, 19 May 2019 18:16 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58641200F3 for <ace@ietfa.amsl.com>; Sun, 19 May 2019 11:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 bb7kC_dvyvfm for <ace@ietfa.amsl.com>; Sun, 19 May 2019 11:16:41 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 1F669120072 for <ace@ietf.org>; Sun, 19 May 2019 11:16:41 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id SQC2hKnhjKkkfSQMShjPoy; Sun, 19 May 2019 18:16:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1558289800; bh=BgEPX7qObRSbP3fEAaScewQj5bGFelInQqlWJMw9R7I=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Mgvhu5NmJqxepEUavn1TnxLqwrLcypMM7KY6uEAPWnuR1SWkgnGW+zC+TYddkJUhh uLU/tXGnCmWurD8iaP+siGVwqcj5657q0+BSHpQyKbCHe+RJXpX6/MDQvpJexwl2qN ue5rnLUIt8BNoVqmwS4/dOszykkM7cURd1A4E0Nu5rOKQhqJLa42q6o/Va72Ne3Ixo AvKXSwHChP67c/ZtaFx93CnrTB7T3QrHq+GlVGVEK4C2fD+iHYZoN6E/SirAMJp6So GZVeibRCnXIgGDM1t96AbRh5cInRtd1NGcJG9Ik3UnqKT2chyczt3aksU/sIcDbyRO jp54FhKxg72wg==
Received: from [IPv6:2601:152:4400:437c:9da0:a575:986d:50be] ([IPv6:2601:152:4400:437c:9da0:a575:986d:50be]) by resomta-ch2-03v.sys.comcast.net with ESMTPSA id SQMRhdQuSxMewSQMRhpqXW; Sun, 19 May 2019 18:16:40 +0000
X-Xfinity-VMeta: sc=0;st=legit
To: ace@ietf.org
References: <DBBPR08MB45393CDF71E7DB02F6C6938CFA330@DBBPR08MB4539.eurprd08.prod.outlook.com> <0a75faf6-0968-d266-b99e-cf400b311477@cisco.com> <AM0PR08MB45328797A4FFEC9ACAFBBEB5FA080@AM0PR08MB4532.eurprd08.prod.outlook.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <c82b5b55-9a8d-cb40-c59e-7e360284d5f3@comcast.net>
Date: Sun, 19 May 2019 14:16:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <AM0PR08MB45328797A4FFEC9ACAFBBEB5FA080@AM0PR08MB4532.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/FqsqdYW_FWRKqh10i72tyLsMr6Q>
Subject: Re: [Ace] EST over CoAP: Randomness
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 May 2019 18:16:43 -0000

On 5/14/2019 7:29 PM, Hannes Tschofenig wrote:
> Hi Paul,
>
> My understanding from reading the draft text was that the "cost" was actually talking about "energy cost" rather than "monetary cost".
> The monetary cost may also be interesting.
>
> It is difficult to judge the extra cost of a RNG in an MCU because
> (a) you rarely find an MCU with and without MCU (keeping all other features the same),
"with and without RNG"?
> (b) even if you find one there are other factors that impact the cost (such as popularity of a particular MCU),
> (c) RNG features are often provided with other features (such as SHA256 and AES in hardware), and
Um... you usually need one or the other of these to do a good 
implementation of a DRBG and hardware versions tend to be less "costly" 
energy wise than software ones.
> (d) cost and price of an MCU are different aspects.

That have no bearing on the protocol design past a certain set of 
minimums.   I'm beginning to think its time for "minimum requirements 
for internet hosts - 2020 edition" RFCs.  We seem to be back in the same 
set of arguments  that ANYTHING should be able to be an internet device 
albiet with even lower thresholds than we were a few years ago.  ACE is 
pushing those boundaries, but we seem to be chasing "cost -> 0"


>
> Ciao
> Hannes


All good points, but ignoring the fact that needs drive the protocols 
which drive the MCU development.  NOT MCUs limit the protocols which 
limit the needs.

In other words, if the community (through protocol definitions) doesn't 
require the RNG, then the MCU developers won't include it.

With respect to RNG energy costs - the argument that they are too 
expensive energy wise is pretty bogus.  RNGs generally have two parts - 
a TRNG or entropy source, and a DRBG seeded from the entropy source.  
The energy costs for the DRBG are microscopic. The energy costs for a 
TRNG are related more to the time needed to initially fill the entropy 
pool (e.g. getting the noisy diodes making noise, getting the ring 
oscillators ringing etc) than to keeping it running to get a few 
thousand bits.  Doing this say once a year to seed the DRBG isn't going 
to kill the lifetime of a battery device.