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 <hannes.tschofe...@arm.com>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

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) <pkamp...@cisco.com>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <hannes.tschofe...@arm.com>; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

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 <ace-boun...@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP: Randomness

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.

_______________________________________________
Ace mailing list
Ace@ietf.org
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.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to