Re: [Secdispatch] [Lake] LAKE next steps

Rene Struik <> Tue, 27 August 2019 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B1E81200F9; Mon, 26 Aug 2019 20:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RLLtDIEfSrkD; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2487F1200C4; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
Received: by with SMTP id o9so42819582iom.3; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=iomDelqHriRuTCFkrUv4NLPM1mkve6YwECWc5zC3HJw=; b=Z0SRXem2Jq0ehB0/NCiWrdNBDgVxWwSMMd80N24itdpy2m7lSrxG4e05c63YPw0bn7 VbvULbmV0QK3RKbaVjVywyE+AhsE7LaKldfSzIrMkoXVovZVQ1vjK42qNVRn2bcqF2tK iKv6SgD73tlWaDsP0g3thbrSK+FDjPT4LzQyThTwRpGVMmk/g1Vy7zkpvHcKnVYpyvWq 8Las4M0My5D/MORelTEIBJDyBu6gbROhounlZ44JQV4DxafcjzG/sSQcUneKr6rdYRAX ggO80+BNRzzF5+Iom2YpkI2XuA+JR2Pa7zD6H9zduSSirsYvTd5yW34+bQ6VlJraVTTl MWjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iomDelqHriRuTCFkrUv4NLPM1mkve6YwECWc5zC3HJw=; b=gNiZ1ps2OfNKWzKkw9PQBWlF4VQI4I08DOb2Ks5j7XJlnIsUxCtGTGsOmgFg3ykuM0 NrHo3A1L9INK2W/MfBnNq0nGjbrsTaZXsHby9LV5KpPz1d/uDEMQXDCZ6b8qH4eCbYu7 g2djq2fSrRL7utaeIAjAzVfkm6wFORuM+9ueErgq+qx4AbPfOUzJk3v8ptX542HHGxE1 zXA/lTRD/JYL3oi4YchVx499TX4R1XiaKz2oEGeaaAmujp6TN0cd/3d3GQmN81xoYwqm tq9PXIopURJUhK7UEqGdyOOQpnEtJa/ogT5z/v/jMWI2rBg8NJdf4UDbtifWu5tn6Kuu dHqQ==
X-Gm-Message-State: APjAAAXPBgNmp/iefwFYSciSS2De2DsceAhvBqHEWhGWdelzwBtgM+at 1N8cvxysVv2AcTLdm10aUswK8IWw
X-Google-Smtp-Source: APXvYqwQsPJwfo5W9GAwZ1aCqTTcucUNVJJo7EKuCorPb+yzvS068s9xpe8v5ds2Zq5Pc0VzW0ZrrQ==
X-Received: by 2002:a02:3004:: with SMTP id q4mr20972376jaq.55.1566876074244; Mon, 26 Aug 2019 20:21:14 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:e464:d5e4:bbba:7a41? ([2607:fea8:69f:f5eb:e464:d5e4:bbba:7a41]) by with ESMTPSA id h3sm16976228iof.65.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 20:21:09 -0700 (PDT)
To: Benjamin Kaduk <>
References: <> <> <>
From: Rene Struik <>
Message-ID: <>
Date: Mon, 26 Aug 2019 23:21:06 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 03:21:17 -0000

On 8/26/2019 4:24 PM, Benjamin Kaduk wrote:
> On Tue, Aug 20, 2019 at 12:13:18PM -0400, Rene Struik wrote:
>> Hi Ben:
>>   From the discussion at the LAKE BoF, it seemed there was strong support
>> [1] for also tackling the broader scenario (triggered by David Thaler's
>> suggested dichotomy at the microphone).
>> I have some trouble seeing suggested next steps on tackling this broader
>> problem in you email below. If you could elaborate on how you see this
>> broader topic ("general purpose lightweight AKE") find a home in terms
>> of next steps, that would be great. (In my mind, this is not simply "TLS
>> with compressed representation".)
> I think we also heard, in addition to the generic "broader problem" hum,
> several explicit statements at the mic about how a reduced-encoding
> "compact TLS" was a good thing, and that having the LAKE discussions may
> have been the trigger needed to make that happen.  So yes, my thinking was
> mostly "TLS with compressed representation" and possibly some additional
> tweaks that are TBD.  Could you elaborate on your thinking for how the
> general-purpose lightweight AKE would differ from "TLS with compressed
> representation"?

RS>> (Procedural.) I reread the draft minutes of the LAKE BoF and found 
15-17 hands for OSCORE and 10-11 for the general case (i.e., both have 
sufficient critical mass). Enthusiasm for other options was not polled 
in the room; hence, my question. You seem to quote Carsten Bormann's 
remark at the mic (according to minutes), but there were many other 
remarks as well, and - arguably - one can cherry-pick any set of remarks 
to arrive at different conclusions. The chartering discussion itself, 
though, did focus on the "narrow" vs. "general" notion David Thaler 
brought to the table and which was discussed in the latter part of the 
BoF meeting. BTW - I still do not understand how TLS with a compressed 
encoding scheme could be considered general. <<RS

RS>> (Technical.) It would be prudent for IETF not to put too many eggs 
in the same basket and, thereby, not have most protocols share the same 
crypto design philosophy, protocol flow framework, and instantiation. 
While arguably convenient, this is contrary to algorithm agility 
requirements (since results in in-tandem vulnerabilities and easily 
ossified code). Hence, my case for not loosing sight of addressing the 
more general problem, with an open mind. I am willing to contribute to 
this and so are 10 others (according to the hum). Arguably, this general 
case cannot presume the Client/Server model, nor semi-infinite resources 
on one of the entities. This being said, this is not a blank slate area 
and closure on fundamental design can be reached in a reasonable, 
limited time frame by experienced people. <<RS

> Thanks,
> Ben
>> Best regards, Rene
>> [1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]):
>> Is OSCORE Key exchange a ('15-the narrow') problem that needs being solved?
>> strong on yes, none on negative question
>> Is broader constrained scenario a problem that needs solving?
>> strong on yes, low on no

[added from minutes]

Willing to work on documents - comment, review, etc.
- 15-17 hands for OSCORE
- 10-11 hands for the general case
- Few overlapping.

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