Subject: Re: [Secdispatch] EDHOC Summary

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 15 Apr 2019 20:47:54 +0000

It seems as if a path forward is a new LAKE WG, not a specific EDHOC WG. Its pretty unanimous and uncontroversial that a lightweight AKE is needed for constrained networks. EDHOC and cTLS are two candidate LAKEs, but neither is a predetermined starting point, let alone winner, yet.

On 12/04/2019 00:08, Göran Selander wrote:
> Hi Richard,
>
> On 2019-04-11, 21:21, "Richard Barnes" <[email-masked]> wrote:
>
>     On Thu, Apr 11, 2019 at 3:15 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Richard Barnes <[email-masked]> wrote:
>         > I'd like to push back on this point. It may be that EDHOC has been around for
>         > a while and been well-socialized with the IoT crowd, but it is clearly
>         > deficient in several other types of maturity, e.g., robustness of formal
>         > analyses and state of implementations (AFAICT).
>
>     I want to be sure that I understand you.
>
>     Is it your opinion tha the IETF can not form a WG until after a protocol has
>     had formal analysis?  How many analysis?  How many years?  Which publications?
>
>
>     I didn't mean anything w.r.t. the formation of a WG.  Carsten's implication seemed to be that an EDHOC WG could deliver more quickly than, e.g., one using TLS as a starting point.  That's the point I was pushing back on -- I hope we agree that delivering
>      a final security protocol should be gated on robust analysis and multiple implementations.
>
> [GS] As I mentioned in my recent reply, given the changes you make to TLS to make message sizes on par with EDHOC, it is a new protocol so the statement about relying on the analysis of TLS is questionable. Comparing implementations there are clearly more of TLS, but, again, this is a new protocol.
>
> Göran
>
>
>
>     --Richard
grsdfsdf

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Apr 2019 07:18:33 +0000

Owen, I am fine with creating a new working group as you suggested below to work on a lightweight AKA.

However, I need to state that there isn’t even a problem with DTLS/TLS 1.2 in IoT networks. The handshake itself is such a small part of the overall communication in the life of an IoT device that focusing the optimization efforts on the handshake is almost ridiculous. Of course, no protocol designer wants to hear that there are system aspects that play a much bigger role in reducing power consumption.

If you consider that the top IoT companies use MQTT protected with TLS using certificates today in their large deployment today then you might even wondering where the large disconnect comes from.

From: Secdispatch <[email-masked]> On Behalf Of Owen Friel (ofriel)
Sent: Montag, 15. April 2019 22:48
To: Göran Selander <[email-masked]>; Richard Barnes <[email-masked]>; Michael Richardson <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; [email-masked]; Martin Thomson <[email-masked]>
Subject: Re: [Secdispatch] EDHOC Summary

On 12/04/2019 00:08, Göran Selander wrote:
> Hi Richard,
>
> On 2019-04-11, 21:21, "Richard Barnes" <[email-masked]<mailto:[email-masked]>> wrote:
>
>     On Thu, Apr 11, 2019 at 3:15 PM Michael Richardson <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
>
>
>     Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
grsdfsdf
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: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Apr 2019 07:26:02 +0000

>         > analyses and state of implementations (AFAICT).

I would like to point out that initially the work on EDHOC was intentionally not positioned as a TLS replacement (or even competitor).
For years I was told that it is supposed to be used in addition to and on top of TLS.

Fast forward a few years the story is very different now.

This type of positioning helps you to avoid dealing with a number of folks in the IETF (in this case with the TLS crowd) but it does not help in the long run.

Ciao
Hannes

PS: FWIW this is not the first time this has happened. ANIMA wasn’t any different when the proponents claimed that IoT was out of scope.
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: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Apr 2019 23:25:23 -0500

Hi Hannes,

> Fast forward a few years the story is very different now.

I'm not sure that this line of discussion is going to be very productive.
Plans can change over time, and of course a technology that is inspired for
one use case can take off and become a key part of designs all over the
place (consider, perhaps, the wild success of the DNS, or as a less extreme
example the wide variety of things people want to do with BRSKI).

The specific technical issue in front of us seems to be a claim that there
is a scenario with wide deployment applicability where the (mostly size)
message constraints are such that stock TLS is not applicable and an
alternative AKE is needed.  This is not surprising given that stock TLS has
not really been designed to skimp on the byte count of message encoding,
though of course we can revisit that aspect of TLS in some ways.

I would welcome technical reasoning that, e.g., the indicated scenario(s)
do not actually have wide deployment applicability, or that stock TLS is in
fact usable in these scenarios, but the history of EDHOC's origins does not
really seem relevant to the technical issues.

Thanks,

Ben