Re: [Ace] EST over CoAP: Randomness

Hannes Tschofenig <> Fri, 24 May 2019 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F97C12016C for <>; Fri, 24 May 2019 09:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3QJwYBBIf_CI for <>; Fri, 24 May 2019 09:52:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69933120139 for <>; Fri, 24 May 2019 09:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aFg7Yy9wWCtCHaeDG6Ugl9jnsHzW5w7MY3yqPuhvJTY=; b=xhmxxjfEq36d4n9NJZYRDm3B3FitJ2nzSjVHMt2kPEemWIGtgIeWlvVsxT9BTayt3ZrESwvB2sf0afu9gKbKXzdjK+k9M5gyQMPXKPPkNuDUquXNYtmo1O0dVgU0zqd3In9nBewV/26YzcQHyA3d4mlC/nvwgfd3Vh/3uqD52do=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Fri, 24 May 2019 16:52:44 +0000
Received: from ([fe80::91a5:7d70:3c7e:d096]) by ([fe80::91a5:7d70:3c7e:d096%6]) with mapi id 15.20.1922.018; Fri, 24 May 2019 16:52:44 +0000
From: Hannes Tschofenig <>
To: Michael StJohns <>, "" <>
Thread-Topic: [Ace] EST over CoAP: Randomness
Thread-Index: AdUGcOnxX76zbRm2S2qe/nEWIh3V6AEMI0QAAAJINfAA8RoFAAD4IHXQ
Date: Fri, 24 May 2019 16:52:44 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ad2cb71c-51b8-48f9-aee5-08d6e0683e6d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4458;
x-ms-traffictypediagnostic: DBBPR08MB4458:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0047BC5ADE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39860400002)(376002)(366004)(40434004)(189003)(199004)(71190400001)(71200400001)(110136005)(25786009)(229853002)(99286004)(7696005)(33656002)(53546011)(316002)(66574012)(68736007)(478600001)(2501003)(66066001)(76176011)(26005)(3846002)(6506007)(2906002)(186003)(6116002)(6246003)(5660300002)(66946007)(66446008)(64756008)(66556008)(66476007)(52536014)(74316002)(72206003)(305945005)(102836004)(8936002)(966005)(7736002)(81156014)(73956011)(9686003)(8676002)(256004)(14444005)(5024004)(53936002)(81166006)(76116006)(55016002)(6306002)(11346002)(86362001)(6436002)(446003)(476003)(486006)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4458;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UA8Wl3EVE1lL+7hPbvoL3deNz6EwEr5n6xirRpUqXtnEn79RsM7gQoUMlijYgOA/2BykbRyRJK7Pp8C/gTBHkgc8fnDHb1cWtisUR0jgb1XrgGFCKZU9SEYiCvknpPlc0konwXRDxebVFOsbSNjY2BZvK7Kbrni9N+fS2IVfCT9LNHuv9fwwzc1DuWUqgJpMCp4SYfAYn8mFPbXE+6xLYOpj4ETebkbYVUL+zQbDCPmcyp7zJ4ytpxIJTbdPz+W9WdVCSPT9D04Y911oWQe4aqKHfJdef3ZXyop2ixydtMukUQBVOxoQE+iTN5R7BlkaSfvtMU2EKWKgJt5SFz0JlbrSXCDeBREotq+yCEqq6nZOGm2yIfXqdndpbTnvPMqnU84DxDhfbU5ZQdHrWHXAGz9SjLB90ChtcCelKSyer0A=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ad2cb71c-51b8-48f9-aee5-08d6e0683e6d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2019 16:52:44.6790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4458
Archived-At: <>
Subject: Re: [Ace] EST over CoAP: Randomness
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 May 2019 16:52:51 -0000

Hi Mike,

A few remarks inline.

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"

[Hannes] Good that you are supporting my argument. I believe this is the first time you agree with me.

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.

[Hannes] You should join the EDHOC discussion where you can hear a lot about how MCUs and networks limit (security) protocols.

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

[Hannes] Luckily silicon vendors already include RNGs in MCUs. That mission got accomplished.

With respect to RNG energy costs - the argument that they are too
expensive energy wise is pretty bogus.

[Hannes] Completely agree with you.
Luckily that text part got changed in the latest version of the draft as a consequence of the recent mailing list discussion.

  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.

[Hannes] Well said. I had hoped that someone would go into the details and you did.
Btw, did you watch my webinar about RNGs ?


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.