Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

[Christopher Wood <[e-mail]>]

Top-posting, since I think clarifying will help answer the comments below.

As observed below, cTLS is underway elsewhere in the IETF. That does *not* mean this WG needs to pick an entirely separate AKE. On the contrary, this WG ought to evaluate -- per the charter -- whether cTLS meets the needs of LAKE. If it does, and if folks favor that AKE, then the primarily outcome of this WG seems to be in formulating requirements which led to that decision. (That would be a fine outcome as far as I'm concerned. The success of a WG is not predicated on how many documents it produces.)

In sum, I think this adoption call is premature and goes against what the charter lays out. Let's do our due diligence here. 
I strongly believe Introducing yet another AKE into the standards pool is something we should not do without serious contemplation.

Best,
Chris

On Sun, Jun 21, 2020, at 5:29 PM, Stephen Farrell wrote:
> 
> Hiya,
> 
> I've a couple of questions below as I don't quite get the
> basis for your conclusion. (I'm not trying to argue your
> conclusion but I don't understand it and would like to.)
> 
> On 22/06/2020 00:51, Christopher Wood wrote:
> > I do not support adoption.
> > 
> > The charter of this WG states:
> > 
> > draft-selander-ace-cose-ecdhe is a candidate starting point for the
> > LAKE produced by the WG. Any work available from TLS or other WGs
> > that satisfies the determined requirements will also be evaluated for
> > suitability, but does not preclude the WG from freely selecting its
> > preferred LAKE for OSCORE.
> > 
> > Unless I missed it, work from TLS was not seriously evaluated for
> > suitability.
> 
> I don't understand what work you mean. cTLS has been
> adopted by the TLS WG and will be developed there. I
> don't understand what useful thing this WG could do
> about that.
>
> > In fact, it seems we jumped right over it and landed on
> > draft-selander-ace-cose-ecdhe.
> 
> Yes. That is the only other serious proposal of which
> I'm aware.
> 
> > The cTLS authors demonstrated that this variant of the protocol can
> > indeed meet the requirements set out in draft-ietf-lake-reqs-04,
> > without compromising any of the benefits that the TLS ecosystem
> > brings to the table. (Support for different server authentication
> > modes, for example, is something TLS is well equipped to support.)
> 
> That's fine, but doesn't seem to speak to this adoption
> call.
> 
> > 
> > I understand that the TLS WG adopted cTLS and will continue its
> > development there. However, that does not seem relevant for what this
> > WG chooses. 
> 
> I really don't understand that. We have 2 serious
> proposals. One will be processed elsewhere. The question
> before us now is whether to pursue the other one or
> not. It seems entirely relevant to me that we are left
> with one or zero things to work on in this WG.
> 
> > By analogy, this would be similar to QUIC developing its
> > own key exchange protocol since UDP is just slightly different from
> > TCP. 
> 
> I don't find that analogy that useful tbh. QUIC is a
> transport area WG chartered to develop a transport
> protocol. This WG was chartered to do work on the topic
> of key exchange, so I don't think the analogy holds.
> 
> > Clearly, that was not the path chosen, and I think it would be a
> >  mistake to do that here without seriously considering cTLS.
> 
> Again - I've no clue what "seriously considering" might
> mean. cTLS is being worked on. If we do not adopt edhoc
> then what would this WG be doing? I don't think is makes
> much sense for a WG to exist merely to "seriously consider"
> a work item in another WG:-)
> 
> Cheers,
> S.
> 
> 
> > 
> > Best, Chris
> > 
> > On Sun, Jun 21, 2020, at 1:13 PM, Jesus Sanchez-Gomez wrote:
> >> Hello All,
> >> 
> >> I support the adoption of this document.
> >> 
> >> I've worked with the technology in research projects/papers
> >> yielding good results.
> >> 
> >> There are several use cases where this technology is a good
> >> solution for different research projects at the University of
> >> Murcia and Odin Solutions.
> >> 
> >> While I've practical experience with this technology working 
> >> specifically in LoRaWAN, its design makes it a good fit for any 
> >> constrained radio link/LPWAN.
> >> 
> >> Also, it has potential to be implemented beyond LPWANs, like more 
> >> generic IoT scenarios with large scalability.
> >> 
> >> Best Regards,
> >> 
> >> 
> >> -- Jesús Sánchez Gómez Contratado predoctoral // Phd Student.
> >> Fundación Séneca. Comunidad Autónoma de la Región de Murcia +34 868
> >> 88 96 74 [phone] [e-mail] Department of
> >> Information and Communication Engineering Faculty of Computer
> >> Science University of Murcia 30100 Murcia, Spain
> >> 
> >> -- Lake mailing list [e-mail] 
> >> https://www.ietf.org/mailman/listinfo/lake
> >> 
> > 
> 
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc