If I’m reading it correctly, it looks like I will be speaking at RSA during that time slot. Can the recording be posted? It’s a tough week for anyone attending, so I suspect attendance will be impacted.
Thank you, Kathleen Sent from my mobile device > On Feb 11, 2019, at 6:13 PM, Roman Danyliw <[email protected]> wrote: > > 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:[email protected]] > Sent: Monday, February 04, 2019 12:30 PM > To: Göran Selander <[email protected]> > Cc: Richard Barnes <[email protected]>; Roman Danyliw <[email protected]>; John > Mattsson <[email protected]>; [email protected]; Francesca > Palombini <[email protected]>; [email protected] > 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 > <[email protected]> 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 <[email protected]> > wrote: > Hi Richard, Roman, all > > Thanks for kind welcome and for progressing the discussion. Apologies for a > long email. > > > From: Richard Barnes <[email protected]> > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > > -- > > Best regards, > Kathleen > > > -- > > Best regards, > Kathleen
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
