Re: [Secdispatch] EDHOC

[Richard Barnes <[e-mail]>]

Not sure what you mean, Kathleen.  This is a public mailing list :)

On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <
[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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" <
> [e-mail]> 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 <
> [e-mail]> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/secdispatch
> >>
> >>
> >
>