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
