Re: [Lake] WG process beyond requirements

Benjamin Kaduk <kaduk@mit.edu> Sun, 02 February 2020 06:26 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A1512004E for <lake@ietfa.amsl.com>; Sat, 1 Feb 2020 22:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orQRPvaKVsT6 for <lake@ietfa.amsl.com>; Sat, 1 Feb 2020 22:26:16 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9CD12008F for <lake@ietf.org>; Sat, 1 Feb 2020 22:26:16 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0126Q6L9030601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Feb 2020 01:26:09 -0500
Date: Sat, 01 Feb 2020 22:26:06 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "lake@ietf.org" <lake@ietf.org>
Message-ID: <20200202062606.GF91553@kduck.mit.edu>
References: <28066505-a174-88e0-c39e-ce04075d4f9e@cs.tcd.ie> <EB9F78C5-B5AB-4A3B-B3FF-C66FF547629B@ericsson.com> <e4707fcf-1561-990b-6bad-607defab6962@cs.tcd.ie> <92B918F6-52B5-48EE-A99B-808F7604889D@ericsson.com> <f5c58aec-39e0-b3f7-4133-5b3bf57861b9@cs.tcd.ie> <12857394-493D-47FC-A8F9-F58038DCCFE9@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <12857394-493D-47FC-A8F9-F58038DCCFE9@ericsson.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/PkqiwDV6_s5iVVSCyL56Jy0wW4M>
Subject: Re: [Lake] WG process beyond requirements
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Feb 2020 06:26:17 -0000

On Tue, Jan 28, 2020 at 04:08:53PM +0000, Göran Selander wrote:
> Hi,
> 
> On 2020-01-28, 16:03, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>     Just as an alternative to consider (i.e., I'm not saying I
>     think this is best, just that it's a possibility), the lake
>     wg could also adopt a draft e.g. if only one (like edhoc)
>     were on offer, but remain open to e.g. ctls turning up later,
>     whenever work on that is completed by the tls wg, which is
>     likely some time ahead I'd say.
>     
>     IOW, adopting a draft soonish (when the requirements are done
>     WGLC), doesn't mean that we need all possible designs that'll
>     ever meet the lake requirements to be at the same stage of
>     development in the very near term.
>     
> 
> GS: I'm all in favor of adopting a candidate fulfilling the requirements as a start and decide on other candidates later. But this is a new turn. One year ago in Secdispatch we were requested to define relevant benchmarks and then to formulate requirements, both of these activities were intended for making comparisons between different protocols. Perhaps that is water under the bridge now.

I don't think the sole (or even primary) reason for desiring
benchmarks/requirements was to have a comparison between protocols, but
rather to ensure that we (collectively) understand the problems we are
trying to solve and that any/all proposed solutions are fit for purpose.

-Ben