Yes, doing anything during the week of RSA is a significant challenge.
Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > On Feb 11, 2019, at 5:29 PM, Kathleen Moriarty > <[email protected]> wrote: > > 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] > <mailto:[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 >> >> <https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc> >> >> Roman >> >> >> From: Kathleen Moriarty [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Monday, February 04, 2019 12:30 PM >> To: Göran Selander <[email protected] >> <mailto:[email protected]>> >> Cc: Richard Barnes <[email protected] <mailto:[email protected]>>; Roman Danyliw >> <[email protected] <mailto:[email protected]>>; John Mattsson >> <[email protected] <mailto:[email protected]>>; >> [email protected] <mailto:[email protected]>; Francesca Palombini >> <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[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] <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ace >> <https://www.ietf.org/mailman/listinfo/ace> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> -- >> >> Best regards, >> Kathleen > _______________________________________________ > Secdispatch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/secdispatch
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
