Re: [Secdispatch] [Lake] LAKE next steps

Benjamin Kaduk <kaduk@mit.edu> Mon, 26 August 2019 20:24 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CD912011C; Mon, 26 Aug 2019 13:24:38 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ei6IATuE97_k; Mon, 26 Aug 2019 13:24:36 -0700 (PDT)
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 97CA0120EE0; Mon, 26 Aug 2019 13:24:36 -0700 (PDT)
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 x7QKOVpD007546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 16:24:34 -0400
Date: Mon, 26 Aug 2019 15:24:31 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rene Struik <rstruik.ext@gmail.com>
Cc: lake@ietf.org, secdispatch@ietf.org
Message-ID: <20190826202430.GL84368@kduck.mit.edu>
References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/9AjOJ-voQ14i1AqaZUwIPJgNH88>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 20:24:38 -0000

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

Thanks,

Ben

> Best regards, Rene
> 
> [1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]):
> Is OSCORE Key exchange a ('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