Agreed Hannes and Esko. For completeness, here is how the updated text looks like. It should cover what we discussed in this thread.
~~~~~~~~~ 5.8. Server-side Key Generation 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 protected]> Sent: Tuesday, May 14, 2019 3:28 PM To: Esko Dijk <[email protected]>; Panos Kampanakis (pkampana) <[email protected]>; [email protected] Subject: RE: [Ace] EST over CoAP: Randomness Esko, your line of thought makes sense to me. I leave it to Panos to enhance the text. Ciao Hannes From: Esko Dijk <[email protected]<mailto:[email protected]>> Sent: Dienstag, 14. Mai 2019 11:57 To: Hannes Tschofenig <[email protected]<mailto:[email protected]>>; Panos Kampanakis (pkampana) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [Ace] EST over CoAP: Randomness 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 protected]<mailto:[email protected]>> Sent: Tuesday, May 14, 2019 18:46 To: Esko Dijk <[email protected]<mailto:[email protected]>>; Panos Kampanakis (pkampana) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [Ace] EST over CoAP: Randomness 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 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. 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 protected] https://www.ietf.org/mailman/listinfo/ace
