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

Karthik Bhargavan <> Tue, 23 June 2020 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E25333A08F3 for <>; Tue, 23 Jun 2020 11:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CIwCvtkiTbyD for <>; Tue, 23 Jun 2020 11:23:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEE483A08EE for <>; Tue, 23 Jun 2020 11:23:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.75,272,1589234400"; d="scan'208";a="352517674"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2020 20:23:06 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Karthik Bhargavan <>
In-Reply-To: <>
Date: Tue, 23 Jun 2020 20:23:04 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: =?utf-8?Q?G=C3=B6ran_Selander?= <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2020 18:23:11 -0000

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.


> On 23 Jun 2020, at 10:11, Göran Selander <> 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" < on behalf of> 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ć <> 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
>> 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
>    -- 
>    Lake mailing list
> -- 
> Lake mailing list