Hi Panos, Thanks for sharing this info.
Regarding the randomness requirement and the energy consumption. We have been a bit advocate for adding hardware-based random numbers to devices since randomness is a basic requirement for most security protocols. You do not only need to have access to random numbers during key generation but also later when you use nonces, a DH exchange, create session keys, and IVs, and potentially even for signature generation. If you use a protocol that is not based on nonces then you may use one that relies on timestamps, which may not make the story necessarily easier. Random number key generation is also not necessarily costly either (neither in terms of energy cost nor in terms of hardware costs). Hence, I think you should consider the server-side key generation very carefully since you are essentially destroying the benefits of public key crypto and introduce a big vulnerability. In a nutshell, I think you are better of recommending OEMs to select the right hardware for the given task. Ciao Hannes PS: For the proxy work (in context of DTLS/TLS) you might want to reach out to your co-worker Owen Friel. From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration ~~~~~~~~~~~~~ Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has shown that cheap endpoints sometimes generate numbers which could allow someone to decrypt the communication or guess the private key and impersonate as the device. Studies have shown that the same keys are generated by the same model devices deployed on-line. 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. The client asks for the server or proxy to generate the private key and the certificate which is transferred back to the client in the server-side key generation response. ~~~~~~~~~~~~~ This is a need that we have heard from customers at Cisco. About the proxy-Registrar question, we already have made the change in the working copy of the draft as well. We no longer call this functionality proxying, but instead use the concept of the registrar that terminates the connection and establishes the next one. We didn't add any new features in the doc after removing the BRSKI stuff. If you want an early preview to comment on, we can share the repository with you. Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 14, 2018 5:05 AM To: ace@ietf.org<mailto:ace@ietf.org> Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding - Explain trust relations for http/coap proxying I have challenged the usefulness of the server-side key generation during the meeting but in general I am curious where we are with the document. It would be great to get it finalized. It appears that we are adding new features and therefore will not be able to complete the work in any reasonable timeframe. So, do we have a plan for how to complete the document? 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
