Re: [6tisch] Progress zero-touch document

["Pascal Thubert (pthubert)" <[e-mail]>]

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ć <[e-mail]>
> Sent: mardi 2 avril 2019 16:59
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; 6tisch <[e-mail]>
> 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) <[e-mail]>
> 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 <[e-mail]> On Behalf Of Mališa Vucinic
> >> Sent: mardi 2 avril 2019 14:55
> >> To: Michael Richardson <[e-mail]>
> >> Cc: 6tisch <[e-mail]>
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/6tisch