Hi Kathleen! Yes. A doodle poll to determine the most agreeable time the week of March 4 was just sent:
https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc Roman From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Monday, February 04, 2019 12:30 PM To: Göran Selander <goran.selan...@ericsson.com> Cc: Richard Barnes <r...@ipv.sx>; Roman Danyliw <r...@cert.org>; John Mattsson <john.matts...@ericsson.com>; secdispa...@ietf.org; Francesca Palombini <francesca.palomb...@ericsson.com>; ace@ietf.org Subject: Re: [Ace] [Secdispatch] EDHOC Will there be an interim for this topic? Thank you, Kathleen On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.i...@gmail.com>> wrote: Thanks for the very helpful message, Goran. A couple of comments inline. On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <goran.selan...@ericsson.com<mailto:goran.selan...@ericsson.com>> wrote: Hi Richard, Roman, all Thanks for kind welcome and for progressing the discussion. Apologies for a long email. From: Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> Summing up where I believe the conversation stands now, it seems like what folks are asking for is either: 1. An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or 2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE) Göran et al: Do you have thoughts on those points? Yes. I’ll get back to this later in this email. It seems like it could be a productive use of an hour or two of virtual interim time to help the group understand one of those lines of argument. Agree. Anything to prevent further hold ups on this work would be appreciated. --Richard As requested in a previous email, here is a background. The work on EDHOC is motivated by the need for an authentication and key exchange protocol for OSCORE (draft-ietf-core-object-security) optimized for constrained-node networks (RFC 7228). OSCORE is applied within the IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security), but also requested by other SDOs and industry fora such as OMA Specworks, Open Connectivity Foundation and Fairhair Alliance. The properties of OSCORE motivating its use include: support for CoAP forward proxies, support for change of underlying transports including non-IP, low overhead, low additional footprint and memory to existing CoAP implementations, support for multicast security, security for end-to-end REST. Given the large interest in OSCORE already before it has become an RFC we anticipate a wide range of deployments. For example, we see an interest for OSCORE in Cellular IoT with traffic running over the cellular air interface control channel, where we can have end-to-end CoAP, but not necessarily end-to-end IP between an application server and a cellular device. Or between an application server and a device behind a cellular gateway. Comparing just these two cases, the difference in capabilities of the devices can be significant which makes it difficult to point at some sort of “reference devices” for benchmarking. In order to support the low end use cases the AKE must be performant in low bandwidth deployments with battery powered devices restricted in RAM and ROM. Message sizes and round trips have a direct impact on latency, power consumption and battery lifetime, and can be calculated which is the reason for this being a commonly used metric. While it may be more difficult to compare memory and storage requirements, the ability to reuse existing code is an important indication. If a device can support a CoAP stack (in the sense of memory and flash, etc) it is expected to also be able to support OSCORE. Similarly, it is desirable that a device with CoAP and OSCORE implemented should be able to support an additional AKE. Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the additional code for EDHOC can be very limited. From a security point of view OSCORE requires that the endpoints have agreed on a Master Secret with a good amount of randomness, and each other’s Sender IDs, and those must be different for a given Master Secret. Now returning to the questions. 1. An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS) Considering EDHOC is a new protocol it should be thoroughly analysed and verified against all currently known issues of AKEs. Roman sent a mail to the secdispatch list referencing a paper presented at SSR 2018 which could be used as a starting point. How do folks want to digest this: Do they want to study the model themselves or should we ask the authors if they could present their work at the interim? 2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE) We have done this comparison with TLS/DTLS for some time now, and what once seemed like a reasonable question has turned out to be never ending exercise. I do not want to get into IETF archeology but for those who have not followed the discussion some data points could be relevant. Not long ago, the design of security protocols did not take into account constrained IoT devices. With OSCORE we showed that the message overhead could be reduced by a factor 3 compared to DTLS 1.2 records. Before this comparison it was believed that the record layer was performing well, then the difference in overhead was characterized as insignificant, and then finally a compact format was designed for DTLS 1.3. With EDHOC we showed that the message overhead of the key exchange can be reduced with up to a factor 4 compared to the current version of DTLS 1.3 (see Appendix E in EDHOC). Before this exercise it was believed that the TLS/DTLS handshake was performing well, then the difference in overhead was characterized as insignificant, and now the discussion has shifted to downsizing the TLS handshake or other protocol. We are not against optimizations to the TLS handshake, just as we welcome the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE for OSCORE optimized for constrained environments. As I remember, optimizing for message overhead was an explicit non-requirement of TLS 1.3. Reverting those design decisions seems like the wrong way to go: One reason to use TLS would be to reuse an existing implementation. But existing TLS implementation would most likely not compare favorably in terms of code size and RAM. Adding code for compression or re-encoding of the messages would add to that. Re-specifying the protocol with the new encoding may require a new formal verification. To make a more compact code and processing may involve two incompatible message formats of TLS depending on what is being signed. New implementations would be needed. We think we have done our part of the comparison exercise and that the burden of proof should now be reversed. Could we ask those that claim to have a more performant key exchange protocol for OSCORE and are prepared to do the work to make that plausible and provide the numbers? To be clear: if there is another key exchange protocol suitable for OSCORE which outperforms EDHOC in constrained characteristics and then we are very interested. I agree with Goran that they have jumped through enough hoops at this point. However, if alternatives come forward, understanding their timelines is also critical as not to hold up this work for any substantial amount of time. And again, with the statements in this mail we neither want to belittle the considerable effort made on formal verification, nor claim that DTLS is not fit for IoT deployments. It is an important hammer in our IoT security toolbox, but at the moment we don’t need a hammer. The class of IoT device seems to be the critical point here and having one protocol that can meet all needs is a nice goal, but not realistic from the comparison numbers provided and the varying requirements in the IoT space. Best regards, Kathleen Göran _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace -- Best regards, Kathleen -- Best regards, Kathleen
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
