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
