Sorry, I thought it was a continuation of a private thread that may also benefit from transparency and additional input.
Thank you, Kathleen Sent from my mobile device > On Jan 18, 2019, at 12:12 PM, Richard Barnes <r...@ipv.sx> wrote: > > Not sure what you mean, Kathleen. This is a public mailing list :) > >> On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty >> <kathleen.moriarty.i...@gmail.com> wrote: >> Can that be a public thread? It really should be. >> >> Sent from my mobile device >> >> > On Jan 18, 2019, at 11:54 AM, Richard Barnes <r...@ipv.sx> wrote: >> > >> > Let me provide some additional context. When the chairs and ADs discussed >> > this in BKK, it seemed pretty clear that EDHOC is not within the current >> > charter of ACE — after all, ACE is targeted at authentication and >> > authorization, not key exchange. Since ACE would need to recharter to >> > accept this work in any case, and because EDHOC overlapped with the >> > interests of other working groups, it seemed to make sense to have the >> > conversation in a broader venue. >> > >> > Göran: Your email starting this thread seems like an abbreviated summary >> > of the past discussion of this draft. Since this is a new audience, it >> > would be helpful if you could start from the underlying requirements (“we >> > need an AKE with certain constraints”) and lay out why new protocol work >> > is needed, vs. profiling existing protocols (as has been done, e.g., in >> > DICE). >> > >> > If it would be helpful to keep this moving, we could certainly arrange a >> > virtual interim on this topic. >> > >> > —Richard >> > >> > >> >> On Jan 4, 2019, at 1:17 AM, Göran Selander <goran.selan...@ericsson.com> >> >> wrote: >> >> >> >> Hi Kathleen, >> >> >> >> Good question. Thanks for bringing continuity to this almost 2 years long >> >> offline discussion. Indeed, lack of comparison with other protocols and >> >> formal verification were at the time the arguments for not following up >> >> the in-room consensus with an email confirmation. And, as you noted, that >> >> is not the case anymore. >> >> >> >> Meanwhile the ACE chairs and AD have changed. My understanding is that >> >> the argument now is about attracting more people with a certain security >> >> competence for which perhaps another WG could potentially be better, >> >> hence the request to Secdispatch. But I'll pass the question on and >> >> include the ACE WG for transparency. >> >> >> >> From the authors' humble point of view we believe that the main missing >> >> thing that would enable the required further discussion is that the IETF >> >> endorses this work, no matter how, so that people dare invest more time >> >> in implementation and analysis. >> >> >> >> Best regards, >> >> Göran >> >> >> >> >> >> On 2019-01-03, 00:58, "Kathleen Moriarty" >> >> <kathleen.moriarty.i...@gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> I’ve read earlier versions of this draft and appreciate all the work >> >> you have done with the security proof and comparing to existing >> >> standardized protocols. If ACE is interested, why is this going to >> >> SECDispatch? It might help to understand that better. Is it that a >> >> recharter would be needed? >> >> >> >> Thank you & happy new year! >> >> Kathleen >> >> >> >> Sent from my mobile device >> >> >> >>> On Jan 2, 2019, at 5:56 PM, Göran Selander <goran.selan...@ericsson.com> >> >>> wrote: >> >>> >> >>> Dear Secdispatch, >> >>> >> >>> We have been advised to ask secdispatch to consider EDHOC: >> >>> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe >> >>> >> >>> Those that follow the ACE WG should be familiar with this draft. The >> >>> problem statement and motivation for EDHOC is described in section 1. In >> >>> brief, the target is a lightweight key exchange protocol suitable for >> >>> IoT applications, which: >> >>> a) has small message size and reuses existing IoT primitives to enable >> >>> low overhead and small code footprint; >> >>> b) is not bound to a particular transport, to enable end-to-end security >> >>> in IoT deployments with varying underlying layers; and >> >>> c) can be used to key OSCORE (draft-ietf-core-object-security) that is >> >>> lacking a harmonizing key exchange protocol. >> >>> >> >>> These requirements are motivated by constrained IoT device deployments, >> >>> but the protocol is applicable to other end-to-end security settings >> >>> where the overhead due to security needs to be low. EDHOC addresses >> >>> these requirements and builds on the SIGMA construction for >> >>> Diffie-Hellman key exchanges.. EDHOC, like OSCORE, is built on CBOR (RFC >> >>> 7049) and COSE (RFC 8152) and the protocol messages may be transported >> >>> with CoAP (RFC 7252). >> >>> >> >>> There has been a number of reviews of different versions of the draft; >> >>> both by people who want to deploy it and by people analysing the >> >>> security. A formal verification was presented at SSR 2018. There are a >> >>> few implementations of different versions of the draft. The ACE WG has >> >>> expressed interest in this work in several f2f meetings. >> >>> >> >>> Please let us know if some information is missing for secdispatch to >> >>> consider this draft, or how we can help out in the process. >> >>> >> >>> Best regards >> >>> Göran, John, Francesca >> >>> >> >>> >> >>> _______________________________________________ >> >>> Secdispatch mailing list >> >>> secdispa...@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/secdispatch >> >> >> >> >> >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
