Subject: [Ace] EST over CoAP: Randomness

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 9 May 2019 14:42:35 +0000

Hi all,

I am still a bit unhappy about this paragraph:

"
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining.
"

If you get hardware that does not have a hardware-based RNG then you are in trouble. The main security protocols we look into do not work without a source of randomness. Hence, getting the certificate & private key from the server will not get you too far.

I believe we should encourage developers to pick the correct hardware for the task rather than making them believe we have come up with solutions that allow them to get away without a hardware-based RNG.

I also do not believe the statement that random number key generation is costly. Can you give me some number?

The references to [PsQs] [RSAorig] are IMHO also not appropriate because they are conveying a different message (at least that's my understanding from reading them). The message is that you have to be careful with designing and using a random number generator on embedded systems because the sources of entropy may just not be there (like keyboards, harddisk drive, processing scheduling, etc.).

Ciao
Hannes

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.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 May 2019 17:33:59 +0200

Hi Hannes,

> On 9 May 2019, at 16:42, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> “

> I also do not believe the statement that random number key generation is costly. Can you give me some number?

I think that statement in particular is troublesome.  Even if we were to believe it to be true today by some measure, is there any reason to believe it will continue to be true?  We need to be raising the bar.

> The references to [PsQs] [RSAorig] are IMHO also not appropriate because they are conveying a different message (at least that's my understanding from reading them). The message is that you have to…

Yes.  And maybe the emphasis of this paragraph should shift as well along these lines.

Eliot

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 10 May 2019 02:52:49 +0000

Thanks Hannes.
Before I try to address it, can you help me understand what you are proposing. To amend this paragraph maybe?

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: [email-masked]
Subject: [Ace] EST over CoAP: Randomness

Hi all,

"

Ciao
Hannes

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 May 2019 08:57:38 +0000

Hi Panos,

I had argued earlier that this feature shouldn't be in the draft but it seems that I will not get there.

Hence, I believe it would be better to first shorten the following paragraph to a single line:

FROM:

"
5.8.  Server-side Key Generation

   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining. Even though the random
   numbers that constitute the identity/cert do not get generated often,
   an endpoint may not want to spend time and energy generating
   keypairs, and just ask for one from the server.

   In these scenarios, server-side key generation can be used.
   ....
"

TO:

"
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the private key the server-side
  key generation should be used.
  ....
"

In the security consideration section I would add a new section somewhere that talks about the random number generation.

"
Random Number Generation

   Modern security protocol require random numbers to be available during
   the protocol run, for example for nonces, ephemeral Diffie-Hellman key
   generation. When the private key is generated by the IoT device then
   the capability to generate random numbers is also needed. When server-
   side key generation is used then the IoT device still needs random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool on laptops or desktop PCs are not available on many IoT devices,
   such as mouse movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be found or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
"

Does this make sense?

Ciao
Hannes

PS: Note that I omitted the reference to RSA because ECC is so much more popular in the IoT space that there is no point in dealing with RSA these days.

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Thanks Hannes.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: [email-masked]
Subject: [Ace] EST over CoAP: Randomness

Hi all,

"

Ciao
Hannes

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 10 May 2019 20:05:42 +0000

Hi Hannes,

> Hence, I believe it would be better to first shorten the following paragraph to a single line:

Note that this paragraph was added from feedback in the review process just to motivate server-side keygen. Given that your proposed text below practically moves the points made in this paragraph in the Sec considerations section, I am all for shortening the paragraph. I was thinking something close to what you wrote, but just to keep a couple of phrases as motivation about the feature without creating an inaccurate sense of security:
~~~~~~~~~~
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the private key the server-side
  key generation should be used. Such scenarios could be when it is considered more secure to
  generate at the server a long-lived random private key that identifies the client or when the
  resources spent to generate a random private key at the client are considered scarce.
~~~~~~~~~~

> In the security consideration section I would add a new section somewhere that talks about the random number generation.

I like your text. I will add it  with minor changes in orange.
~~~~~~~~~~
   Modern security protocols require random numbers to be available during
   the protocol run, for example for nonces, ephemeral EC Diffie-Hellman key
   generation. This capability to generate random numbers is also needed
   when the constrained device generates the private key (that corresponds
   to the public key enrolled in the CSR). When server-side key generation is
   used, the constrained device depends on the server to generate the
   private key randomly, but it still needs locally generated random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool used to generate random numbers on laptops or desktop PCs
   are not available on many constrained devices, such as mouse
   movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be used or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
~~~~~~~~~~

I hope it makes sense.

Panos

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Panos,

FROM:

"

TO:

"

"
Random Number Generation

Does this make sense?

Ciao
Hannes

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Thanks Hannes.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: [email-masked]
Subject: [Ace] EST over CoAP: Randomness

Hi all,

"

Ciao
Hannes

---

From: Esko Dijk <[email-masked]>
Date: Fri, 10 May 2019 21:33:38 +0000

Hi Panos, Hannes,

Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain certificates must be created by the systems under direct control of the IT department. (E.g. to comply with other policies or to be able to trust the randomness level. Or just because that was the way it always has been when PCs were provisioned with certificates.)  This could be listed as an additional reason.

Best regards
Esko

From: Ace <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, May 10, 2019 22:06
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Ace] EST over CoAP: Randomness

Hi Hannes,

I hope it makes sense.

Panos

-----Original Message-----
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Panos,

FROM:

"

TO:

"

"
Random Number Generation

Does this make sense?

Ciao
Hannes

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Thanks Hannes.

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] EST over CoAP: Randomness

Hi all,

"

Ciao
Hannes

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf..org/mailman/listinfo/ace<https://www.ietf.org/mailman/listinfo/ace>
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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 May 2019 16:41:28 +0000

Your text updates look good to me, Panos.

Thanks.
Hannes

From: Panos Kampanakis (pkampana) <[email-masked]>
Sent: Freitag, 10. Mai 2019 13:06
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Hannes,

I hope it makes sense.

Panos

-----Original Message-----
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Panos,

FROM:

"

TO:

"

"
Random Number Generation

Does this make sense?

Ciao
Hannes

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Thanks Hannes.

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] EST over CoAP: Randomness

Hi all,

"

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 May 2019 16:46:23 +0000

Hi Esko,

good to hear from you.

  *   Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain certificates must be created by the systems under direct control of the IT department. (E.g. to comply with other policies or to be able to trust the randomness level. Or just because that was the way it always has been when PCs were provisioned with certificates.)  This could be listed as an additional reason.

For readers interested in making informed decisions I believe it is worthwhile to point out that they need random number generation capabilities on IoT devices – not just for the private key generation in context of the EST exchange. I fear that some people, including IT managers, just glance over the details and focus on isolated aspects. I am sure you agree with me that this would be a too simplistic view.

Ciao
Hannes

---

From: Esko Dijk <[email-masked]>
Date: Tue, 14 May 2019 18:56:32 +0000

Hi Hannes,

Agree. The draft is already referencing RFC 7925, so it could additionally reference Section 12 (https://tools.ietf.org/html/rfc7925#section-12) which explains that randomness is also needed for all DTLS handshakes. What I mention about “being able to trust the randomness level” is then maybe a more psychological requirement rather than technical. A powerful server with RTC just sounds more capable to do private key generation than an IoT device, which is why server-side keygen may be preferred ;)

Esko

From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, May 14, 2019 18:46
To: Esko Dijk <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Esko,

good to hear from you.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 May 2019 19:28:20 +0000

Esko,

your line of thought makes sense to me. I leave it to Panos to enhance the text.

Ciao
Hannes

From: Esko Dijk <[email-masked]>
Sent: Dienstag, 14. Mai 2019 11:57
To: Hannes Tschofenig <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Hannes,

Esko

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 14, 2019 18:46
To: Esko Dijk <[email-masked]<mailto:[email-masked]>>; Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Esko,

good to hear from you.

Ciao
Hannes

---

From: Paul Duffy <[email-masked]>
Date: Tue, 14 May 2019 18:07:48 -0400

> I also do not believe the statement that random number key generation is costly. Can you give me some number?

Strong agreement.  The added cost for hw based RNG is ever decreasing.  
Last time I checked it was on the order of 50 cents @ Q 10k?  It has 
likely fallen since.  Confirm with Atmel etc.

Cheers

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 May 2019 23:29:00 +0000

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),
(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
(d) cost and price of an MCU are different aspects.

Ciao
Hannes

-----Original Message-----
From: Paul Duffy <[email-masked]>
Sent: Dienstag, 14. Mai 2019 15:08
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Ace] EST over CoAP: Randomness

> I also do not believe the statement that random number key generation is costly. Can you give me some number?

Strong agreement.  The added cost for hw based RNG is ever decreasing. Last time I checked it was on the order of 50 cents @ Q 10k?  It has likely fallen since.  Confirm with Atmel etc.

Cheers

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 May 2019 10:10:41 -0400

My understanding of the use case for server generated keys is for existing,
deployed systems where the system can easily get a firmware update, but the
hardware TPM itself is unable/unwilling to generate new keys, and can't be
upgraded, but keys can be loaded.

Systems like Hannes' company produces, where the TPM is really a TEE don't
suffer from the upgrade problem, but there are many other systems out there
based upon older designs.

And, it's an optional part of the protocol; one I don't intend to support.
I don't see why it should bother anyone.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Damm, Benjamin" <[email-masked]>
Date: Wed, 15 May 2019 14:28:40 +0000

Low-throughput RNG should be a must for IoT. Certainly in our environment devices that are unable to generate keys would be unacceptable. Hopefully we won’t codify such an abomination in any protocol.
-Ben

Benjamin Damm
Cell: +1-415-297-5474
Web: https://Itron.com

________________________________
From: Ace <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Sent: Tuesday, May 14, 2019 4:29 PM
To: Paul Duffy; [email-masked]
Subject: [EXTERNAL] Re: [Ace] EST over CoAP: Randomness

Hi Paul,

Ciao
Hannes

-----Original Message-----
From: Paul Duffy <[email-masked]>
Sent: Dienstag, 14. Mai 2019 15:08
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Ace] EST over CoAP: Randomness

Cheers

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.
_______________________________________________
Ace mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ace&d=DwICAg&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=dH_774yB0_IzrwFvyY1Iio9qthZz-eV34lbAEv3Y3kY&s=WChHRMoeN8IO06GYZPU1yk3uh76KEHoR7q9Hx7nhGcs&e=

---

From: Paul Duffy <[email-masked]>
Date: Wed, 15 May 2019 10:30:18 -0400

The point I'm making Hannes is that,  though not so long ago the "cost" 
for RNG was prohibitive for many constrained end-devices ... this is 
more often no longer the case and improving every month (despite 
whatever other security functions are packaged within the module).

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 15 May 2019 15:12:09 +0000

The draft is not recommending against RNGs in any way and hopefully there will be no room for such misunderstandings in the updated text.
Panos

From: Ace <[email-masked]> On Behalf Of Damm, Benjamin
Sent: Wednesday, May 15, 2019 10:29 AM
To: Hannes Tschofenig <[email-masked]>; Paul Duffy (paduffy) <[email-masked]>; [email-masked]
Subject: Re: [Ace] [EXTERNAL] Re: EST over CoAP: Randomness

Low-throughput RNG should be a must for IoT. Certainly in our environment devices that are unable to generate keys would be unacceptable. Hopefully we won't codify such an abomination in any protocol.
-Ben

Benjamin Damm
Cell: +1-415-297-5474
Web: https://Itron.com

________________________________
From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 14, 2019 4:29 PM
To: Paul Duffy; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [Ace] EST over CoAP: Randomness

Hi Paul,

Ciao
Hannes

-----Original Message-----
From: Paul Duffy <[email-masked]<mailto:[email-masked]>>
Sent: Dienstag, 14. Mai 2019 15:08
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] EST over CoAP: Randomness

Cheers

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 15 May 2019 16:46:34 +0000

Agreed Hannes and Esko.

For completeness, here is how the updated text looks like. It should cover what we discussed in this thread.

~~~~~~~~~

In scenarios where it is desirable that the server generates the private key, server-side key generation should be used. Such scenarios could be when it is considered more secure to generate at the server the long-lived random private key that identifies the client, or when the resources spent to generate a random private key at the client are considered scarce, or when the security policy requires that the certificate public and corresponding private key are centrally generated and controlled. Of course, that does not eliminate the need for proper random numbers for various protocols like (D)TLS (Section 10.1).
[ … ]

10.1. EST server considerations
[ … ]
Modern security protocols require random numbers to be available during the protocol run, for example for nonces, ephemeral EC Diffie-Hellman key generation. This capability to generate random numbers is also needed when the constrained device generates the private key (that corresponds to the public key enrolled in the CSR). When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925]. Additionally, the transport of keys generated at the server is inherently risky. Analysis SHOULD be done to establish whether server-side key generation enhances or decreases the probability of identity stealing.

It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. Other sources have to be used or dedicated hardware has to be added. Selecting hardware for an IoT device that is capable of producing high-quality random numbers is therefore important.
[ … ]
~~~~~~~~~

I am planning to reupload by the end of the week.

Rgs,
Panos

From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, May 14, 2019 3:28 PM
To: Esko Dijk <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: [Ace] EST over CoAP: Randomness

Esko,

Ciao
Hannes

From: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Sent: Dienstag, 14. Mai 2019 11:57
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Hannes,

Esko

Hi Esko,

good to hear from you.

Ciao
Hannes

---

From: Michael StJohns <[email-masked]>
Date: Sun, 19 May 2019 14:16:38 -0400

> (a) you rarely find an MCU with and without MCU (keeping all other features the same),
"with and without RNG"?
> (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

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 May 2019 16:52:44 +0000

Hi Mike,

A few remarks inline.

"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),
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.

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

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

[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 -

[Hannes] Well said. I had hoped that someone would go into the details and you did.
Btw, did you watch my webinar about RNGs https://www.youtube.com/watch?v=xQF2U6AkSjI ?

Ciao
Hannes