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
