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

Rene Struik <> Tue, 23 June 2020 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB2DF3A0A62 for <>; Tue, 23 Jun 2020 13:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZqwwvLO4KgdD for <>; Tue, 23 Jun 2020 13:59:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E66163A0A40 for <>; Tue, 23 Jun 2020 13:59:57 -0700 (PDT)
Received: by with SMTP id r22so18702624qke.13 for <>; Tue, 23 Jun 2020 13:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Zi0arH/vgmmB24ZYPqboeSLsBOlRJhL9yw7eo1wOUac=; b=WOpER63lcVlf/rfvgIdsifcqgtjLPkeeJfJpXkzz4CiQGeon6pg2c3yuHxuVFDxzCv q2IoZfnwSIsg/TPLHqcdif7RpAcSQh6qP4xx/LPu5dSJoV4QFFjK0hY5CayK3/g8cve2 nWJappR2L5ahHqOWpV9J+SaZIoKabnUqcfmDz1CRWpjcP3+k0eWMvj7kMsRxw2wXLDtB GLt6nZPM59JCIGZAr8yPrQyxD+CoMgK3tVNNaIHuoMYmYJKV4CG69X5QaDk/dxUIrwm/ WlcuYowZYARYw0c/BCDJesrrYPBcBu10jhGME5OYvs9lJU40gH60epav2J9B/3mH8kSF xnjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Zi0arH/vgmmB24ZYPqboeSLsBOlRJhL9yw7eo1wOUac=; b=scCS8hGFnYPlXymCJCyB/8KRXLTinfEDwxFyTKMQIfFXG9CtiVZwNCzC4AxHxv6wxv RKbyH20bcAuFzeTw4Y61Y3xD/7VmKbVirrdzN1oCNCqao+MFGKzJHTCu9GycWNFaZtaS 133I/Z0RoEqbp83DjK5pCYMGuIlQxYBLHookkfv0C8ypbQYE9uULi7RgIpbBbY8hleif h6Ru45OGexSCriFVQkxlKvGfYYykMpUnylaRHFZ11do9l4+G/t5AM8NpLt5MP7SSFtug eQVfxVSRyMxuJQDUi8bYqPsFHXLf/fIqUQ1INluhhI1TDUZewIKNHfcBGZ1V/kWpMztp T3cw==
X-Gm-Message-State: AOAM533dJEGzJkb4VIYyY30lGh4tYevni6IwLgeHLpiYz1R5I0CRXdex ZMTfkXHFmxrJ2H5/Uu5CGWaJZJCJ
X-Google-Smtp-Source: ABdhPJzTngEKoQMOnt4hhi+FOl1GCeid1IvIdI/bYURvWs0WccwMbehNh+NFD+VmLuU2WUcP6Hi9vg==
X-Received: by 2002:a37:6894:: with SMTP id d142mr22308882qkc.440.1592945996465; Tue, 23 Jun 2020 13:59:56 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:e5f4:e73b:8e31:101d? ([2607:fea8:8a0:1397:e5f4:e73b:8e31:101d]) by with ESMTPSA id p22sm1759739qtc.7.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 13:59:55 -0700 (PDT)
To: Karthik Bhargavan <>, "" <>
References: <> <> <> <>
From: Rene Struik <>
Message-ID: <>
Date: Tue, 23 Jun 2020 16:59:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 21:00:00 -0000

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

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

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