Re: [Secdispatch] [Lake] LAKE next steps

Benjamin Kaduk <kaduk@mit.edu> Wed, 28 August 2019 16:50 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 D003F120232; Wed, 28 Aug 2019 09:50:31 -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 dJnaKcSF-Upq; Wed, 28 Aug 2019 09:50:29 -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 882E01200B2; Wed, 28 Aug 2019 09:50:29 -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 x7SGoOOt012419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 12:50:26 -0400
Date: Wed, 28 Aug 2019 11:50:23 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rene Struik <rstruik.ext@gmail.com>
Cc: lake@ietf.org
Message-ID: <20190828165023.GE84368@kduck.mit.edu>
References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/jFimJGPJxa958gKD-SuB7Nj8BRY>
X-Mailman-Approved-At: Wed, 28 Aug 2019 10:08:27 -0700
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: Wed, 28 Aug 2019 16:50:32 -0000

[secdispatch@ again to bcc]

Hi Rene,

On Mon, Aug 26, 2019 at 11:21:06PM -0400, Rene Struik wrote:
> 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

I fear I'm still confused or don't understand your point, or perhaps what
you mean by "general".  Would you disagree if I said that "TLS is the de
facto general-purpose communications security protocol for the Web"?  What
about if I replaced "Web" with "Internet"?  If the core protocol is
general-purpose, does it not remain general-purpose if the encoding is
compressed?  The best way I can find to interpret your remark is that the
"general-purpose constrained use case" has different requirements than an
Internet-wide general-purpose communications protocol, but (1) I'm not very
confident that's what you mean, and (2) even if that is what you mean, I
don't know that anyone has tried to do a survey for what those specific
requirements would be and how they might differ from the Internet case.

> 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

I actually do not take it as a given that, when working with a fixed set of
resources, diversity of design/implementation is always the most optimal
approach, regarding "eggs in the same basket" -- there are tradeoffs to be
made and the analysis may produce different results in different
situations.

With respect to your request to not lose sight of addressing the more
general problem, I note that the current charter under discussion is
explicitly targetting just the OSCORE use case, with intent to ask the TLS
WG to consider cTLS.  If you feel that this is not adequately addressing
what you see as the "more general problem", then please suggest an
alternate course of action, whether that is an edit to the proposed LAKE
charter, a draft charter for a separate WG, or some other proposal.  As it
is, I have to guess what you want to see happen, and my track record for
guessing is not great.

Thanks,

Ben