No, I'm saying that maybe we can refrain from publishing in the next weeks till the decision is made to form the group. Hopefully that's not too long!
All the best, Pascal > -----Original Message----- > From: Mališa Vučinić <[email protected]> > Sent: mardi 2 avril 2019 16:59 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: Michael Richardson <[email protected]>; 6tisch <[email protected]> > Subject: Re: [6tisch] Progress zero-touch document > > Hello Pascal, > > Are you suggesting that we should start working out the details on using > EDHOC but keep an alternative as an appendix in the document? Since we > have stalled on this work for some time for reasons outside of the working > group control, I think it would make sense to catch up.. > > Let me know. > > Mališa > > > On 2 Apr 2019, at 15:34, Pascal Thubert (pthubert) <[email protected]> > wrote: > > > > Hello Malisa > > > > Speaking for myself here, I'm happy that you start on that direction > > already; > but would like to see the edhoc group formed and progressing before > committing fully to it. > > > > All the best, > > > > Pascal > > > >> -----Original Message----- > >> From: 6tisch <[email protected]> On Behalf Of Mališa Vucinic > >> Sent: mardi 2 avril 2019 14:55 > >> To: Michael Richardson <[email protected]> > >> Cc: 6tisch <[email protected]> > >> Subject: [6tisch] Progress zero-touch document > >> > >> Michael, all, > >> > >> With the EDHOC specification finally seeing progress (see [1]), it > >> seems like a good time to restart the work on zero touch and progress > >> the adopted working group document. > >> > >> Reading the current version of > >> draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it seems that there > >> are many options available, including the choice between DTLS and > >> EDHOC for authentication. Many available options may pose > >> interoperability challenges and also add unnecessary code complexity. > >> Given that the working group decided on using OSCORE during network > >> access [2], as well as for application purposes [3], the > >> implementation of the 6TiSCH stack includes the CBOR/COSE primitives > >> in the footprint, as well as the support to go through an > >> application-layer proxy as specified in [2]. EDHOC protocol is built > >> on these primitives, can be easily carried within messages specified > >> in [2] for network access to go through an application-layer proxy, > >> and is quite efficient when it comes to the encoding overhead using CBOR > resulting in a small number of L2 frames to complete the key exchange. It > seems as a natural way forward for the working group to focus on using > EDHOC in [4]. > >> > >> Therefore, I would like to propose to keep track of the EDHOC > >> progress and to work on a more streamlined zero-touch solution. Doing > >> these changes in [4] seems to make the most sense at this point. > >> > >> What are your thoughts on this? > >> > >> Mališa > >> > >> [1] > >> https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHa > >> fWj > >> XIm0c > >> [2] > >> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ > >> [3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ > >> [4] > >> https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotou > >> ch- > >> join/ > >> _______________________________________________ > >> 6tisch mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
