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

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

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 <[e-mail]>
Cc: [e-mail]
Subject: RE: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

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 <[e-mail]<mailto:[e-mail]>>
Sent: den 25 juni 2020 12:25
To: Blomqvist, Peter <[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 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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 25, 2020 12:07 PM
To: Hannes Tschofenig <[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 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 <[e-mail]<mailto:[e-mail]>>
Sent: den 25 juni 2020 11:22
To: Blomqvist, Peter <[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 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<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=>

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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 25, 2020 9:27 AM
To: Hannes Tschofenig <[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

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]<mailto:[e-mail]>> On Behalf Of Hannes Tschofenig
Sent: den 24 juni 2020 12:51
To: Karthik Bhargavan <[e-mail]<mailto:[e-mail]>>; 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

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