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

["Blomqvist, Peter" <[e-mail]>]

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 <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: den 24 juni 2020 12:51
To: Karthik Bhargavan <[e-mail]>; Rene Struik <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

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

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



                                Anyway, my two cents: let’s not forget the time needed for formal analysis before deploying a protocol on a billion devices.

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

On 2020-06-23 2:23 p.m., Karthik Bhargavan wrote:
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=[e-mail]<mailto:goran.selander=[e-mail]>> wrote:

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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

   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ć <[e-mail]<mailto:[e-mail]>> 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:

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

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.
--
Lake mailing list
[e-mail]<mailto:[e-mail]>
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
   [e-mail]<mailto:[e-mail]>
   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
[e-mail]<mailto:[e-mail]>
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=>


--
email: [e-mail]<mailto:[e-mail]> | Skype: rstruik
cell: [phone] | US: [phone]

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.