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

From: Mališa Vučinić <[email-masked]>
Date: Mon, 8 Jun 2020 15:54:37 +0200

Hi all,

Since we now have a rough consensus on the requirements document, we are proceeding with the selection of the LAKE for OSCORE our working group is chartered to work on. Given:

- the LAKE working group charter,
- a wide community support over an extensive period of time for draft-selander-lake-edhoc,
- adoption of the cTLS draft by the TLS working group where it will be further developed,
- that no other drafts have been submitted for consideration of the LAKE working group, 

we are now launching a call for adoption for https://tools.ietf.org/html/draft-selander-lake-edhoc-01 <https://tools.ietf.org/html/draft-selander-lake-edhoc-01>.

Please reply to this thread whether you support the adoption, and indicate if you are ready to review if this draft becomes a working group document.

The call for adoption ends on June 22nd, 2020.

Your LAKE chairs.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Jun 2020 16:58:48 -0400

Mališa Vučinić <[email-masked]> wrote:
    > we are now launching a call for adoption for
    > https://tools.ietf.org/html/draft-selander-lake-edhoc-01
    > <https://tools.ietf.org/html/draft-selander-lake-edhoc-01>.

    > Please reply to this thread whether you support the adoption, and
    > indicate if you are ready to review if this draft becomes a working
    > group document.

I support this document. I have read it several times, and I will review it.
I am also partially through an implementation.

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 9 Jun 2020 13:57:13 +0200

Hello Mališa, hello LAKE group,

> indicate if you are ready to review if this draft becomes a working

I've read the -00 and skimmed -01 with special focus on the changed
sections. I especially appreciate the addtition of the repudiation
paragraph in the security considerations.

The document might need some updating with respect to the requirements
document, especially in terminology (took me a bit to find that for
"certificates by refernce", I'll need to look for 'x5u' in there), but
that puts it at a stage where I would prefer to have this as a working
group document.

I'm looking forward to extending the two OSCORE implementations (aiocoap
for large systems, libOSCORE for constrained devices) that I've written
to use this, and to experimentation with it over the various links CoAP
can be used on.

Kind regards
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

---

From: Dan Garcia <[email-masked]>
Date: Thu, 11 Jun 2020 15:37:24 +0200

Hello all,

I support the adoption of this document as wg document.

We as a collaboration between Odin Solutions and the University of 
Murcia are involved in the development of EDHOC implementation and  
OSCORE to be tested in different products of Odin Solutions. Our 
objective is to release open implementations when ready, following the 
current draft version.

We see potential in EDHOC in different use cases and we intend to 
collaborate as we can.

Best Regards.

On 08/06/2020 15:54, Mališa Vučinić wrote:
> Hi all,
>
> Since we now have a rough consensus on the requirements document, we 
> are proceeding with the selection of the LAKE for OSCORE our working 
> group is chartered to work on. Given:
>
> https://tools.ietf.org/html/draft-selander-lake-edhoc-01.
>

---

From: "Eduardo Ingles (UM)" <[email-masked]>
Date: Fri, 12 Jun 2020 05:49:09 +0200

Hello, LAKE WG,

I am currently studying the use cases of EDHOC in IoT networks for my 
PhD. In particular, I am studying the role of EDHOC in its integration 
within the life cycle of IoT devices.

EDHOC has some features that could be advantageous for IoT. Therefore, I 
look forward to the adoption of this document.

Kind regards.

-- 
Eduardo Inglés Sánchez
[email-masked]

Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

---

From: Martin Disch <[email-masked]>
Date: Sat, 13 Jun 2020 22:28:40 +0200

> Please reply to this thread whether you support the adoption, and indicate if you are ready to review if this draft becomes a working group document.

As part of a thesis I built a proof-of-concept implementation of EDHOC
in the Rust programming language available at
https://github.com/martindisch/oscore. The naming of the repository is
due to the subject being both EDHOC and OSCORE on embedded devices,
but the following refers only to the EDHOC implementation.

It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly,
outdated. Since it was just one part of the overall work, I only
managed to implement the subset I needed, which is RPK and the
signature-signature based scheme (corresponding to what
draft-selander-lake-edhoc calls method 0). I also took some other
shortcuts, such as not supporting auxiliary data. Fortunately, test
vectors were about to be introduced just around the time I was working
on it, so I've been able to successfully verify my implementation
against them when John shared them with me for some preliminary
testing. Since I didn't have any prior experience implementing this
kind of software, I would definitely consider it more of an
experiment, but it's out there and it works, in case it can be useful
to anybody.

I'm convinced that EDHOC will be valuable particularly in the context
of OSCORE, possibly even beyond that. As for the draft itself, I would
like to mention one aspect that I think could be improved from the
perspective of an implementer. Part of the promise of EDHOC is that
it's simple and lightweight due to reusing COSE. That is certainly the
case, but breaks down somewhat when working on a system where no fully
featured library for it is available. This was the case for me and I
personally found it difficult to quickly figure out which aspects of
COSE I needed to implement. The draft does a good job of pointing to
the right places in RFC 8152, but I still ended up trying to
understand another ~100 page document just to implement the few
constructs I actually needed. I know the authors are aware of this and
there has been some effort to inline more information directly in the
specification, which I greatly appreciate. It would be very nice to
have an entirely self-contained document to work with. But I have to
again point out my lack of experience in that area, it's entirely
possible that this draft is in fact much better than others in this
regard and I just don't know it yet.

With that I would like to support the adoption and am looking forward
to seeing how it develops.

Kind regards,

Martin

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 16 Jun 2020 08:59:37 +0200

Hi,

I support this document,

I've implemented the SCHC compression rules and the performances are good.

Laurent

On Mon, Jun 8, 2020 at 3:55 PM Mališa Vučinić <[email-masked]>
wrote:

> Hi all,
>
> Since we now have a rough consensus on the requirements document, we are
> proceeding with the selection of the LAKE for OSCORE our working group is
> chartered to work on. Given:
>
> Please reply to this thread whether you support the adoption, and indicate
> if you are ready to review if this draft becomes a working group document.
>
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake
>

---

From: Rikard Höglund <[email-masked]>
Date: Thu, 18 Jun 2020 15:45:38 +0000

Hello.

I support the adoption of this document.

I have been working on an implementation of OSCORE and integrating it into the Californium library, and I am also working on an implementation of Group OSCORE. In addition I have been doing work on adding support for OSCORE to the LWM2M Leshan framework. EDHOC can be useful for establishing keys, as OSCORE in Californium currently only supports pre-shared symmetric keys.

Best wishes
Rikard Höglund
RISE
________________________________
From: Lake <[email-masked]> on behalf of Mališa Vučinić <[email-masked]>
Sent: Monday, June 8, 2020 15:54
To: [email-masked] <[email-masked]>
Subject: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi all,

we are now launching a call for adoption for https://tools.ietf.org/html/draft-selander-lake-edhoc-01.

Your LAKE chairs.

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 18 Jun 2020 20:53:03 +0200

Hi all,

Best,
/Marco

On 2020-06-08 15:54, Mališa Vučinić wrote:
> we are now launching a call for adoption
> for https://tools.ietf.org/html/draft-selander-lake-edhoc-01.
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: sandoche Balakrichenan <[email-masked]>
Date: Thu, 18 Jun 2020 22:18:30 +0200

Sandoche.

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Sun, 21 Jun 2020 13:34:14 +0000

I support this document and LAKE moving forward.

We are working with libOSCORE on our platform (Cat-M1 / NB-IoT bearers, potentially BT and also group communication).

We tried the initial implementation of EDHOC by University of Murcia and look forward to broader adoption/support to refine an integrated SW stack.

Best
Peter

---

From: Jesus Sanchez-Gomez <[email-masked]>
Date: Sun, 21 Jun 2020 22:13:44 +0200

Hello All,

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
+34 635 33 26 09
[email-masked]
Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 21 Jun 2020 16:51:38 -0700

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.
In fact, it seems we jumped right over it and landed on draft-selander-ace-cose-ecdhe.
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.)

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. By analogy, this would
be similar to QUIC developing its own key exchange protocol since UDP is just slightly
different from TCP. Clearly, that was not the path chosen, and I think it would be a 
mistake to do that here without seriously considering cTLS. 

Best,
Chris

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jun 2020 01:29:16 +0100

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:
> 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.
> 

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.

> 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

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
>> 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.
>> 
>> -- 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 +34 635 33 26 09 [email-masked] Department of
>> Information and Communication Engineering Faculty of Computer
>> Science University of Murcia 30100 Murcia, Spain
>> 
>> -- Lake mailing list [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Jun 2020 17:31:15 -0700

I don't think it's surprising that I also don't favor adoption. In
general, I believe that there are a lot of advantages to reusing an
existing AKE, because we inherit not only the analysis of that AKE but
also all the work that goes into extending it, both in the past and in
the future.

I do think there are settings where it makes sense to standardize a
new AKE. For example, group messaging is a radically different setting
and therefore designing a new AKE (MLS) was a much better idea than
trying to repurpose one of our existing ones (TLS, IKE, or GKMP,
etc.). However, in this case we have a setting which is quite similar
to that for which TLS was designed and differs primarily in message
size. Were this setting radically simpler than the TLS setting,
then it might still make sense to design something new, but as
I read the requirements, they're actually not particularly simple
and it seems likely they will eventually expand.

This leaves us with the question of message size. However, as cTLS
appears to be able to meet the consensus message size requirements, I
do not believe it is necessary to adopt and standardize EDHOC.

-Ekr

On Sun, Jun 21, 2020 at 4:52 PM Christopher Wood <[email-masked]>
wrote:

> development there.

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 21 Jun 2020 17:38:22 -0700

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:
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jun 2020 01:51:09 +0100

Hiya,

On 22/06/2020 01:38, Christopher Wood wrote:
> 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.)

Hmm. I think both edhoc and cTLS could, in their final
incarnation, meet the requirements and that that's fairly
clear. What am I missing? I don't get what work needs to
be done to establish that, and assume that WG participants
can do whatever evaluation is needed for themselves.

> 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'm still confused about the basis for the above TBH.

> I strongly
> believe Introducing yet another AKE into the standards pool is
> something we should not do without serious contemplation.

That, however, is quite clear and seems to me a valid
basis from which to argue against adopting edhoc. (Noting
that "valid" does not mean "winning.")

Cheers,
S.

>> 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.)
>> 
>>> 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.
>>> 
>> 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.
>> 
>> 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.
>> 
>>> 
>>> 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.
>> 
>> 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
>>> 
>>>> Also, it has potential to be implemented beyond LPWANs, like
>>>> more generic IoT scenarios with large scalability.
>>>> 
>>>> Best Regards,
>>>> 
>>>> 
>>>> Fundación Séneca. Comunidad Autónoma de la Región de Murcia +34
>>>> 868 88 96 74 +34 635 33 26 09 [email-masked] Department
>>>> of Information and Communication Engineering Faculty of
>>>> Computer Science University of Murcia 30100 Murcia, Spain
>>>> 
>> Attachments: * 0x5AB2FAF17B172BEA.asc * signature.asc
>

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 21 Jun 2020 17:53:01 -0700

On Sun, Jun 21, 2020, at 5:51 PM, Stephen Farrell wrote:
> clear. What am I missing? 

If this is the case, why are we already considering adopting and moving forward with EDHOC?

Best,
Chris

---

From: Melinda Shore <[email-masked]>
Date: Sun, 21 Jun 2020 21:37:52 -0800

> moving forward with EDHOC?

It's historically been a matter of policy that the IETF lets the
market choose the winning technology, rather than choosing it
ourselves.  I think it's led to a lot of waste, both because
we end up putting a lot of effort into things that never see
much (or any) deployment and because we end up solving the same
problems over and over and over again (talking to middleboxes,
let me count the ways), but it strikes me as consistent
with existing practice to do both EDHOC and cTLS, and then seeing
what falls out.  That is to say, if you really want to see EDHOC
not move forward it's probably best to either provide a strictly
technical argument or argue that the time has come for the IETF
to start selecting the "correct" way to solve each problem.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Jun 2020 05:54:15 +0000

I object to the adoption of EDHOC.

My reason is primarily the worry about fragmentation in the IoT ecosystem being introduced with this solution path. Over time EDHOC will be extended to cover all the use cases of TLS/DTLS. This will also lower interoperability for IoT-based solutions.

Having said that I understand that there are different motivations at play when working in the IETF. Hence, I can hardly blame consultants and researchers on this list to get excited about introducing more solutions. Unfortunately, we know from prior IETF security standardization that more solutions have actually led to weaker security in deployments.

Ciao
Hannes

From: Lake <[email-masked]> On Behalf Of Mališa Vucinic
Sent: Monday, June 8, 2020 3:55 PM
To: [email-masked]
Subject: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi all,

Your LAKE chairs.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Jun 2020 08:50:42 +0200

On 2020-06-22, at 07:54, Hannes Tschofenig <[email-masked]> wrote:
> 
> researchers on this list to get excited about introducing more solutions

Right, thank you for reminding me that I still have to reply.

I’m quite happy that EDHOC has caused CTLS to emerge.  That will certainly cause some fragmentation, but it is a step long overdue for TLS/DTLS.  I believe we need to continue working on creating the environment that will lead to CTLS actually getting completed.  I don’t mind if Hannes calls this environment “getting excited”; creating mindshare is often how technology progresses.

I don’t think that CTLS obviates the need for EDHOC, for reasons that should by now well-expressed inside and outside this mailing list.
So I am in favor of adopting draft-selander-lake-edhoc as a working group document of LAKE.

I’d make some meta-comments on design for choice, but those would just lead to more unneeded discussion.  Can choice damage the Internet or its applications?  It sure can.  Perspectives on this differ, and few people will manage to control the influence on this perspective from their desire for a specific outcome.  Competition has already managed to significantly improve both sides.  Enough said.

Grüße, Carsten

---

From: Shahid Raza <[email-masked]>
Date: Mon, 22 Jun 2020 23:17:31 +0200

A strong +1 for adoption.

It's been discussed repeatedly and has shown by empirical numbers that
OSCORE and EDHOC are lightweight and better-suited for IoT use cases.

Best,

Shahid

Director of Cybersecurity at RISE

On Mon, Jun 22, 2020 at 8:50 AM Carsten Bormann <[email-masked]> wrote:

> I’m quite happy that EDHOC has caused CTLS to emerge.  That will certainly
> cause some fragmentation, but it is a step long overdue for TLS/DTLS.  I
> believe we need to continue working on creating the environment that will
> lead to CTLS actually getting completed.  I don’t mind if Hannes calls this
> environment “getting excited”; creating mindshare is often how technology
> progresses.
>
> I don’t think that CTLS obviates the need for EDHOC, for reasons that
> should by now well-expressed inside and outside this mailing list.
> I’d make some meta-comments on design for choice, but those would just
> lead to more unneeded discussion.  Can choice damage the Internet or its
> applications?  It sure can.  Perspectives on this differ, and few people
> will manage to control the influence on this perspective from their desire
> for a specific outcome.  Competition has already managed to significantly
> improve both sides.  Enough said.
>
> Grüße, Carsten
>
> --
> Lake mailing list
> [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Jun 2020 17:49:08 -0400

Hi all,

I oppose adoption of EDHOC, for both process and technical reasons.

At the process level, it is ridiculous to move for adoption immediately
after declaring consensus on the requirements.  Unless you're going to use
the requirements to evaluate solutions, there's no point having them, and
there has been no discussion on this list as to how the two solutions
compare in light of the agreed requirements.

Mališa, Your call for adoption also incorrectly suggests that because cTLS
has been adopted by TLS and no other drafts have been submitted to LAKE,
then EDHOC is basically the only option.  That is not true -- the group
could declare consensus that the focus should be on cTLS, declare victory,
and close down.  That would also fulfill the charter.

I continue to believe that cTLS is a better option for solving this
problem.  From the beginning, those of us involved in cTLS have pointed out
that having more choices for security protocols in the ecosystem has
costs.  We have also put forward concrete protocol proposals, backed by
implementation, that show that cTLS can meet the requried constraints.
Neither argument has been addressed by the EDHOC proponents.

More directly, it is hard to evaluate whether EDHOC is a suitable starting
point given that it has been a very dynamic target over the last several
versions, and earlier iterations have had security issues.  Starting from
the thoroughly-vetted baseline of TLS is a safer approach than designing
from whole cloth.  One can focus on specific questions around the things
that are being changed, rather starting analysis all over again.

I also believe that the IETF should focus its work on protocols that will
have real-world impact.  It is clear that EDHOC is popular among
academics.  Opinion appears much more split among people who work on
shipping code for real IoT devices.  Until we can get some real consensus
among actual implementors, we should not move forward.

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jun 2020 23:07:15 +0100

Hiya,

> I oppose adoption of EDHOC, for both process and technical reasons.

I don't see how your process reasons add up tbh, but
maybe I'm wrong...

> after declaring consensus on the requirements.  

That is kinda funny tbh. This topic has been discussed for
a significant duration. IMO people have clearly reached
their reasoned conclusions either way well before now. I
see no real possibility that more time will change
positions and no new information being offered that might
have that effect.

> Unless you're going to use

It seems clear to me that both edhoc and cTLS can meet the
requirements. Feel free to correct me as to why that is
wrong.

> and close down.  That would also fulfill the charter.

If the consensus were to not adopt edhoc, I will be arguing
to close the WG as it'd be pointless. That seems to me to
amount to the same decision that you argue for above.

To be clear about something I've said before: as a chair, I
am not personally willing to put up with procrastinating
further on what is a clear choice that needs to be made and
on which I believe all informed participants have reached
their own considered decisions. There are non-trivial
arguments on both sides, but I don't see that there have
been any new arguments nor information for some time. It
is time to pick or get off the picking-pot.

Cheers,
S.

>> if you are ready to review if this draft becomes a working group document..
>>

---

From: Sean Turner <[email-masked]>
Date: Mon, 22 Jun 2020 23:45:21 -0400

I totally get Melinda’s point that in the past we have let the market decide. Here there is already an AKE that is very widely deployed does what is needed. The AKE just needs to be slimmed, everything needs to be slimmed in the constrained space apparently ;}, so I really think we ought to just do the slimming because of the KISS principle. So, I tend think LAKE could use cTLS and call it day.

spt

> On Jun 8, 2020, at 09:54, Mališa Vučinić <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 23 Jun 2020 14:00:16 +1000

> https://tools.ietf.org/html/draft-selander-lake-edhoc-01.

I was reluctant to respond to this thread, because it generally isn't worth stopping other people from doing something they want to do.  And I'm aware that the contract implied by the formation of this working group - at least in the minds of many - was the development of a new AKE.

The time that others spend isn't the only factor we should use to decide.  As others have noted, adoption of an entirely new AKE means more than just the time that those other people spend.  I have no skin in the maintenance of IoT products, but the concerns raised about fracturing and maintenance overheads there are serious.  My concern is for the split this creates between endpoints that choose option A and endpoints that choose option B.

When CoAP was proposed, I didn't have the same presence of mind as others [1] to recognize the harm inherent in defining something like HTTP that wasn't HTTP.  It's easy to point to adoption of CoAP and use that to claim success, but that misses the true costs.  The true failure is the creation of a set of endpoints that don't talk to other endpoints.  The IETF made the choice to actively help create a division in the market.  Maybe these endpoints might never have been able to communicate (MQTT is, after all, largely outside our control), but the choice by the IETF to XKCD 927 didn't really help.

For us, this failure manifests in a great deal of expenditure on parallel infrastructure and standards development.  For the market, who we leave to choose, the cost is in the creation of non-interoperable islands.  The market also pays through the dilution of resources that we dedicate to the improvement of the commons, of which protocols are some of the most valuable assets.

[1] https://tools.ietf.org/html/draft-montenegro-httpbis-h2ot-00

---

From: Göran Selander <[email-masked]>
Date: Tue, 23 Jun 2020 08:11:25 +0000

Some reflections on the responses to the adoption call.

LAKE is about designing an AKE for OSCORE. 

We have heard from of the order of 10 people from different organisations who have worked with OSCORE implementations and some also with EDHOC, and they all support the adoption of EDHOC. 

We have heard a number of statements from people or organisations who are documented against OSCORE, because it is competing with solutions they are promoting or for some other reason.  In deciding about what draft to base the AKE for OSCORE, how should we weigh the advice from people/organisations who do not want OSCORE to be deployed at all?  For all I know, they could promote an AKE which is not at all suitable for the purpose.

We have not heard a single witness from someone who actually have tested OSCORE with cTLS, let alone testing with good performance, despite cTLS has been around for 15 months.  There is a good reason why: no one wants to use that combination.

While in theory it sounds like a good idea to re-use a slimmed TLS handshake, this has been a theory for such a long time that we can now add the lack of proof points to the list of reasons why this is not a good idea.  The burden of proof to demonstrate that cTLS is suitable for OSCORE rests with cTLS.  Yes, we have recently concluded the requirements phase, but the requirements on how to make an AKE for OSCORE has been unchanged for as long as cTLS has existed. 

It is also claimed by several that cTLS fulfils the LAKE performance requirements. Yet others make assessments about adoption based on that assumption.  I may have missed it, but I have have not seen any text making plausible, for example, that running a complete handshake messages over CoAP for RPK by reference in (1,1,1) fragments.  Note that this is not just a detail, it is one major reason for "L" in LAKE.  It is my understanding that re-engineering TLS to the point where it meets the LAKE requirements is no longer TLS, neither in terms of analysis nor implementation. 

As a summary, I think many of the arguments against adoption are based on assumptions that may be incorrect, or at least, despite the long time this has been debated, for some reason have not been shown. 

Göran

On 2020-06-23, 05:45, "Lake on behalf of Sean Turner" <[email-masked] on behalf of [email-masked]> wrote:

    spt

---

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 23 Jun 2020 20:23:04 +0200

Hello all.

I don’t have a strong personal opinion on this adoption call.

However, whichever protocol the working group chooses to work on, it is important that we leave sufficient time for multiple comprehensive security analyses,
including both symbolic analyses and cryptographic proofs that cover all corners of the protocol.

I cannot speak for all my academic colleagues, but in general, we prefer to work on a single stable protocol that we know will have a high impact.
Historically, this has meant TLS, which is why there are dozens of papers covering every aspect of TLS under multiple security models.
These analyses don’t just covert the cryptographic code, they also account for non-core features like negotiation and resumption.
My sense is that it will probably be easy to adapt many of these results to apply to cTLS, but this still needs to be done.
But we also need to make sure we get similar levels of assurance for EDHOC, and we are only at the early stages of this analysis.

In my team, we are planning to build a comprehensive analysis of both cTLS and LAKE using F* and this will take some time.
I see there are other efforts on analysing EDHOC using Tamarin, which is great, and I don’t know if some team is planning a cryptographic proof of the protocol.
Anyway, my two cents: let’s not forget the time needed for formal analysis before deploying a protocol on a billion devices.

Best,
-Karthik

> On 23 Jun 2020, at 10:11, Göran Selander <goran.selander=[email-masked]> wrote:
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 23 Jun 2020 16:59:51 -0400

Hi Karthik:

I don't think you intended it this way, but your note seemed to suggest 
that support for another twist of a protocol by academia is motivated 
by, at least partially, "because it is a nice academic paper generator"...

I would encourage everyone to look beyond one's own niche and consider 
wider scale ramifications and considerations as well.

There is still lots of new stuff to work on or to dream up, rather than 
analyzing things people write up in internet drafts... {I hope you agree 
-- if not, contact me and we can discuss some topic areas to consider 
and that I would love to spend time on if having sufficient time for this}

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 24 Jun 2020 07:22:01 +0200

Hi Rene,

> I don't think you intended it this way, but your note seemed to suggest that support for another twist of a protocol by academia is motivated by, at least partially, "because it is a nice academic paper generator"...

Quite the contrary. Perhaps my email was unclear, but we usually prefer to have a few stable protocols that we can analyze with multiple subtly different models over several years.

Analyzing an IETF protocol standard takes a lot of time, and is largely a thankless task. Most of my colleagues could write 3 papers in the time it takes them to fully specify a single protocol standard.
This is certainly not an efficient paper generator. We do it, like all of you, because we think it is important for the Internet community.

My main point is that if we want similar levels of assurance for EDHOC that we obtained for TLS 1.3, we need to budget some time for this, and cannot rush towards standardization.
Of course, the WG may decide that LAKE does not need the same level of rigor as TLS 1.3, which would be unfortunate.

Best,
Karthik

> I would encourage everyone to look beyond one's own niche and consider wider scale ramifications and considerations as well.
> 
> There is still lots of new stuff to work on or to dream up, rather than analyzing things people write up in internet drafts... {I hope you agree -- if not, contact me and we can discuss some topic areas to consider and that I would love to spend time on if having sufficient time for this}
> 
> 
> Best regards, Rene
> 
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jun 2020 10:32:16 +0100

Hiya,

On 24/06/2020 06:22, Karthik Bhargavan wrote:
> Analyzing an IETF protocol standard takes a lot of time, and is
> largely a thankless task.

Well, fwiw, I'm really thankful to all the people (yourself
included) who were involved in analysis of TLS1.3 and who
are willing to put in the effort to analyse IETF protocols.
I think that was a fine model to follow any time we can
motivate people to do such analysis.

> My main point is that if we want similar levels of assurance for
> EDHOC that we obtained for TLS 1.3, we need to budget some time for
> this

I agree. If the WG adopts edhoc then we will want to allow
for that work too.

Cheers,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Jun 2020 10:51:11 +0000

<rant start>

I would like to point out that it also takes a while to produce high-quality, embedded implementations and to deploy these protocols.

While there was the desire within some part of the IoT community to re-use as much as possible from the available IETF protocol stack, this idea was been forgotten over the years. As a result, a parallel world of specifications was created solely for IoT. In most cases, not even the authors (or the companies they work for) bother to implement and deploy the protocols they are creating.

As this email thread shows there is little incentive for most IETF participants to object to anything. It costs time & energy and only leaves unhappy people behind. Nobody wants that. Area directors are not of much help either because they want to get re-elected. Hence, some of them have actually helped to create the situation we are currently in. On the positive side, most of you will move on after finishing your current research project and so you do not have to deal with the collateral damage.

<rant end>

From: Lake <[email-masked]> On Behalf Of Karthik Bhargavan
Sent: Wednesday, June 24, 2020 7:22 AM
To: Rene Struik <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Rene,

Best,
Karthik

Best regards, Rene

Hello all.

Best,
-Karthik

On 23 Jun 2020, at 10:11, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>> wrote:

Göran

On 2020-06-23, 05:45, "Lake on behalf of Sean Turner" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   spt

On Jun 8, 2020, at 09:54, Mališa Vučinić <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Your LAKE chairs.
--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake
   --
   Lake mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/lake

--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Jun 2020 15:54:31 -0700

Hi all,

In light of some of the directions that the recent discussion on this
thread has gone, I want to take a step back and confirm my understanding of
what it would mean for this adoption call to succeed.

My own personal understanding of the "at most one LAKE" in the charter is
that a decision to go from one candidate output of the WG to zero (and,
presumably, close the WG) could be made at any time prior to the
publication of such a "one LAKE.  Specifically, among the myriad
possibilities that seemed plausible at the time of chartering, one
possibility included (1) the WG reaching consensus on requirements; (2) adopting
EDHOC to polish it, perform enough analysis to assure ourselves that it
provides the requisite security properties, and confirm that it fulfils the
LAKE requirements; and then, (3) as the TLS WG had been doing the same for cTLS
(perhaps modulo "confirm that it fulfils the LAKE requirements"), decide
that the benefits gained by standardizing the new AKE (EDHOC) did not
outweigh the costs of specifying a new AKE on the Internet ecosystem, and
close the WG having not published any documents.

So it remains unclear to me whether we are being asked to consider "should
we spend time to do the polishing/analysis in (2) above", or if we are
being asked to (implicitly) consider something like (3) above, i.e., is
EDHOC or cTLS a better outcome for the greater Internet ecosystem.

While I have not had the opportunity to closely follow the technical
developments on either the EDHOC of cTLS protocols, I do know that
advancements have been made.  Perhaps they are both sufficiently well
developed that we have enough information to answer (3) at this time, but
it's not fully clear to me that we are all in agreement as to what is being
asked.

Thanks,

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Jun 2020 00:07:10 +0100

Hiya,

I'm confused as to why this is confusing tbh;-)

> EDHOC or cTLS a better outcome for the greater Internet ecosystem.

Let me try this way:

- TLS has adopted cTLS. That will follow IETF process
  and turn into an RFC or not.
- The question here is whether or not this WG wants to
  adopt edhoc, and then follow the usual IETF process
  which will turn that into an RFC, or not.

If this WG adopts edhoc, one or both of cTLS and edhoc
might or might not end up as an RFC.

If the WG don't adopt edhoc, then yes, it'd be time to
shut up shop for this WG is my guess.

It is also true that once a WG adopts a draft, it is
quite likely to end up as an RFC, but that is not the
question we're answering now, and is not one we can
answer, as it requires an IETF last call etc.

Does that help?

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Jun 2020 16:42:40 -0700

> I'm confused as to why this is confusing tbh;-)

Fair enough :)

> answer, as it requires an IETF last call etc.

That all sounds good, thanks.

-Ben

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Thu, 25 Jun 2020 07:27:21 +0000

Hannes,

There is one quite prominent counter example of “IoT actually re-using protocols”:
Amazon IoT. The MQTT/TLS protocols can be supported on our device platform ” using standard components such as mbedTLS.

Disregarding battery life this works fine:
This particular stack does not work very well for battery powered devices in high latency power save modes or conditions with marginal signal strengths.

Best
Peter

From: Lake <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: den 24 juni 2020 12:51
To: Karthik Bhargavan <[email-masked]>; Rene Struik <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

<rant start>

<rant end>

From: Lake <[email-masked]<mailto:[email-masked]>> On Behalf Of Karthik Bhargavan
Sent: Wednesday, June 24, 2020 7:22 AM
To: Rene Struik <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

we are now launching a call for adoption for https://tools.ietf.org/html/draft-selander-lake-edhoc-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dselander-2Dlake-2Dedhoc-2D01&d=DwMGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=ReOhyTHbHxF59rwa6NKLJmWnWtc32YE99Fj4rlHBZBM&m=d3Mmx53LDWYEWoMTH08XP8Cu4vwNl7xEqapJd86MoY4&s=i-HANYX-4HPpyDRjnTigxGmpz3tksgEfYQdodrKNfpo&e=>.

Your LAKE chairs.
--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lake&d=DwMGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=ReOhyTHbHxF59rwa6NKLJmWnWtc32YE99Fj4rlHBZBM&m=d3Mmx53LDWYEWoMTH08XP8Cu4vwNl7xEqapJd86MoY4&s=H_Jzab9FgwA_l1j1k-Ec87XO1gOgA9NDw8eG-_NAQ80&e=>
   --
   Lake mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/lake<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lake&d=DwMGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=ReOhyTHbHxF59rwa6NKLJmWnWtc32YE99Fj4rlHBZBM&m=d3Mmx53LDWYEWoMTH08XP8Cu4vwNl7xEqapJd86MoY4&s=H_Jzab9FgwA_l1j1k-Ec87XO1gOgA9NDw8eG-_NAQ80&e=>

--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lake&d=DwMGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=ReOhyTHbHxF59rwa6NKLJmWnWtc32YE99Fj4rlHBZBM&m=d3Mmx53LDWYEWoMTH08XP8Cu4vwNl7xEqapJd86MoY4&s=H_Jzab9FgwA_l1j1k-Ec87XO1gOgA9NDw8eG-_NAQ80&e=>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Jun 2020 09:22:00 +0000

Hi Peter,

Amazon IoT is in fact a good example that supports my argument.

When the IETF decided that HTTP and MQTT does not work well for IoT devices it created CoAP. Fine so far. Neither MQTT nor HTTP went away – actually the opposite happened. Both protocols got enhanced to become more performant. Luckily all three use the same underlying security mechanism (at least up to the point when OSCORE came along).

What does this mean for us (Arm): we now have to support HTTP, MQTT, and CoAP. Nothing goes away.

To give you a recent example of what we are doing see the talk by my co-worker Reinhard Keil:
https://www.embeddedonlineconference.com/session/How_to_Rapidly_Develop_IoT_devices_with_Arm_and_AWS

On the note about power consumption: this is a complex topic on embedded system and very often it has little to do with the actual key exchange protocol but rather with the crypto, with the underlying OS, with the features you are using on the MCU, etc. Happy to talk more about Mbed TLS, if you are interested. There are many configuration settings (as with all embedded stacks) and you need to select what is most appropriate for your environment to get the maximum out of it.

Ciao
Hannes

From: Blomqvist, Peter <[email-masked]>
Sent: Thursday, June 25, 2020 9:27 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hannes,

Best
Peter

From: Lake <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: den 24 juni 2020 12:51
To: Karthik Bhargavan <[email-masked]<mailto:[email-masked]>>; Rene Struik <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Thu, 25 Jun 2020 10:07:12 +0000

Hi Hannes,

I agree AWS IoT can quickly be deployed – much thanks to ARM!

But it’s a bit inconsistent to recognize CoAP but not OSCORE – both sprung from same IETF process driven by IoT needs.
The session establishment is definitely a large contributor in cellular especially in bad conditions:
We are trouble shooting a product where one location yields magnitudes worse stamina than nominal.

Best
Peter

From: Hannes Tschofenig <[email-masked]>
Sent: den 25 juni 2020 11:22
To: Blomqvist, Peter <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Peter,

To give you a recent example of what we are doing see the talk by my co-worker Reinhard Keil:
https://www.embeddedonlineconference.com/session/How_to_Rapidly_Develop_IoT_devices_with_Arm_and_AWS<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.embeddedonlineconference.com_session_How-5Fto-5FRapidly-5FDevelop-5FIoT-5Fdevices-5Fwith-5FArm-5Fand-5FAWS&d=DwMGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=ReOhyTHbHxF59rwa6NKLJmWnWtc32YE99Fj4rlHBZBM&m=oujvoWU2nRItujg2zR6614hOgqQRjbghWr0oRj4ensY&s=pE7rIsFQCwezdNhtsMj7pvV8F32C17hPMbxSJ_29RQk&e=>

Ciao
Hannes

From: Blomqvist, Peter <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 25, 2020 9:27 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hannes,

Best
Peter

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Jun 2020 10:25:18 +0000

Hi Peter,

I actually opposed also to the standardization of OSCORE for a number of reasons but that is history now.

I agree that the handshake had to be optimized and the standardization effort in optimizing has produced a number of results already. Sadly, only a small number of them got implemented.
If I try to take a positive aspect out of the entire LAKE discussion then it is the start of the cTLS work (as Carsten phrased it).

I would like to investigate whether cTLS is all that is needed to cover your use cases and other use cases brought up in the group. Doing that using some recent embedded hardware and an off-the-shelf software stack would be interesting. Happy to collaborate with you on such a project.

Ciao
Hannes
From: Blomqvist, Peter <[email-masked]>
Sent: Thursday, June 25, 2020 12:07 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Hannes,

Best
Peter

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: den 25 juni 2020 11:22
To: Blomqvist, Peter <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Peter,

Ciao
Hannes

Hannes,

Best
Peter

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Thu, 25 Jun 2020 14:26:48 +0000

Hannes,

We can provide some input on use-cases and current issues we face with (D)TLS:.
Also please clarify “cTLS” – is that for key export or full replacement of OSCORE?

Best
Peter

From: Hannes Tschofenig <[email-masked]>
Sent: den 25 juni 2020 12:25
To: Blomqvist, Peter <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Peter,

Ciao
Hannes

Hi Hannes,

Best
Peter

Hi Peter,

Ciao
Hannes

Hannes,

Best
Peter

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Thu, 25 Jun 2020 16:27:39 +0000

Just to clarify my previous mail: Throughout the discussion it has been claimed that cTLS is a solution to LAKE but I have not seen any mention in the discussion or in draft-ietf-tls-ctls how cTLS is used with OSCORE.

We can continue discussing the other, unrelated mbedTLS topics I had in mind, outside the list, and preferably after vacation.

Best
Peter

From: Blomqvist, Peter
Sent: den 25 juni 2020 16:27
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hannes,

Best
Peter

Hi Peter,

Ciao
Hannes

Hi Hannes,

Best
Peter

Hi Peter,

Ciao
Hannes

Hannes,

Best
Peter

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 26 Jun 2020 08:56:55 +0000

Hi Peter,

  *   We can provide some input on use-cases and current issues we face with (D)TLS:.

This would be highly appreciated and timely given that there is this TLS / DTLS profile work ongoing in the UTA working group.

  *   Also please clarify “cTLS” – is that for key export or full replacement of OSCORE?

cTLS refers to the approach of compressing TLS. Here is the draft: https://tools.ietf.org/html/draft-ietf-tls-ctls-00
It has applicability beyond IoT, which is why the TLS working group adopted it.

OSCORE is conceptually similar to the TLS/DTLS record layer. The most natural way of using DTLS/TLS or cTLS would be to use it with its native record layer. Then, you obviously don’t need OSCORE.
For example, in this email thread Hari from u-blox referenced the work he did at u-blox as part of a government funded research project to protect CoAP from an IoT device over BLE to a gateway and then to the cloud. He is using OSCORE in his setup. We are using DTLS 1.2 over BLE (and then over WebSocket) in a commercial deployment where we protect CoAP entirely (end-to-end*) without using OSCORE.  We call this ATLS (application layer TLS) because TLS (or DTLS) is carried (at least in some segments of the communication path at the application layer). The ATLS spec (see https://tools.ietf.org/html/draft-friel-tls-atls-04) also adds a description on how to derive keying material for OSCORE.

Ciao
Hannes

(*): The term “end-to-end” is often over-sold because in most cases CoAP communication isn’t truly end-to-end. So, in practice one has to be careful to figure out what the “end points” in the communication are.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Robert Cragie <[email-masked]>
Date: Fri, 26 Jun 2020 11:36:56 +0000

Hi Hannes,

Further to your example, as mentioned earlier, Thread Commissioning [1] also secures CoAP end-to-end using DTLS through a number of middleboxes. See figure 11 in [1], where the JOIN_FIN req.rsp messages are CoAP messages in the joining session, secured all the way from the untrusted joining device over an insecure first hop to the Commissioner (which could be cloud-based). Note also that the Commissioner is typically a smart phone, for which there are readily-available TLS implementations thus making development of a commissioning app for Thread [2] relatively straightforward. The OpenThread stack [3] for developing Thread-based devices uses a single instance of the mbedTLS library for Thread Commissioning, where that library is also available for application layer security in the device. Thread does use a non-standard cipher suite based on EC-JPAKE [4] but it was relatively straightforward to add this cipher suite to mbedTLS using the existing framework and building blocks already in place.

Note all of this predates ATLS but the principles are exactly the same. ATLS caters for a wider range of use cases.

Robert

[1] https://www.threadgroup.org/Portals/0/documents/support/CommissioningWhitePaper_658_2.pdf
[2] https://play.google.com/store/apps/details?id=org.threadgroup.commissioner
[3] https://openthread.io/
[4] https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01

Sent: 26 June 2020 09:57

Hi Peter,

Ciao
Hannes

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Fri, 26 Jun 2020 16:36:56 +0000

Hi Hannes,

Thanks for the references. I was aware of an earlier version of ATLS but have not read the details. However, this does not seem to match the performance requirements of LAKE.

Coming back to use-cases I mentioned earlier, one scenario is “edge” where we are interested in the Group OSCORE functionality, for which we want to reuse the OSCORE code (We are in a project where at least three parties have started integrating OSCORE into their device/cloud platforms).

Let’s talk more after the vacations.

Best

Peter

________________________________
From: Blomqvist, Peter
Sent: 25 June 2020 18:27
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Best

Peter

From: Blomqvist, Peter

Hannes,

Best

Peter

Hi Peter,

Ciao
Hannes

Hi Hannes,

Best

Peter

Hi Peter,

Ciao

Hannes

Hannes,

Best

Peter

<rant start>

<rant end>

Hi Rene,

Best,

Karthik

Best regards, Rene

Hello all.

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 28 Jun 2020 20:43:36 -0700

Hi Martin,

Thanks for chasing this line of inquiry.  It does leave me with some more
questions, though...

> I was reluctant to respond to this thread, because it generally isn't worth stopping other people from doing something they want to do.  And I'm aware that the contract implied by the formation of…

(Sure, though for me I was more interested in the "find out if we need to
develop a new AKE" question, first.)

> When CoAP was proposed, I didn't have the same presence of mind as others [1] to recognize the harm inherent in defining something like HTTP that wasn't HTTP.  It's easy to point to adoption of CoA…

The main thread I'd like to tug on here is what exactly could be
interoperable, and how that might be affected by our decisions here in
LAKE.  In particular, it seems like we need to take the existence of CoAP
and OSCORE as a given, and cannot indulge in counterfactuals.  So, given
that there are devices using CoAP, and OSCORE is 8613, we can expect people
to be making devices that use OSCORE for their secure communications, and
need an AKE to key OSCORE for most/many use cases.  This already assumes
an "island" separate from HTTP, and an island separate from TLS for data
protection.  Is using cTLS as an AKE for OSCORE going to somehow (help)
join up an island of cTLS+OSCORE with the existing CoAP+DTLS island?
If we want a cTLS stack to talk to a non-'c' TLS stack, even just for the
AKE, where is the translation logic going to be (if it's even possible)?

My own first cut at an analysis is only finding that we'd "just" avoid
having separate EDHOC+OSCORE and cTLS+OSCORE islands, but that a
cTLS+OSCORE island would still be an island, isolated from the broader TLS
ecosystem.  Am I missing a way to join things together?

> For us, this failure manifests in a great deal of expenditure on parallel infrastructure and standards development.  For the market, who we leave to choose, the cost is in the creation of non-inter…

That is true, though it is unclear to me that there is any effort ("market"
or otherwise) currently going into a cTLS+OSCORE combination.  I'd love to
be illuminated if I've just been missing it!

Thanks,

Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 29 Jun 2020 07:37:33 +0000

Hi Peter,

  *   Just to clarify my previous mail: Throughout the discussion it has been claimed that cTLS is a solution to LAKE but I have not seen any mention in the discussion or in draft-ietf-tls-ctls how cTLS is used with OSCORE.

The story is to use cTLS with ATLS. ATLS describes how to carry a TLS/DTLS handshake at the application layer and to establishment keying material for OSCORE (and other things). This is inline with what has been done previously, for example with VoIP media security and DTLS-SRTP.

  *   We can continue discussing the other, unrelated mbedTLS topics I had in mind, outside the list, and preferably after vacation.

Sounds like a plan. Enjoy your vacation.

Ciao
Hannes

Best
Peter

From: Blomqvist, Peter

Hannes,

Best
Peter

Hi Peter,

Ciao
Hannes

Hi Hannes,

Best
Peter

Hi Peter,

Ciao
Hannes

Hannes,

Best
Peter

<rant start>

<rant end>

Hi Rene,

Best,
Karthik

Best regards, Rene

Best,
-Karthik

Göran

   spt

Hi all,

Your LAKE chairs.