Re: [Lake] Alissa Cooper's Block on charter-ietf-lake-00-00: (with BLOCK)

Benjamin Kaduk <kaduk@mit.edu> Fri, 04 October 2019 22:00 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 6B3C8120020; Fri, 4 Oct 2019 15:00:15 -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 BPkV3QR5W_fc; Fri, 4 Oct 2019 15:00:10 -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 5AE41120024; Fri, 4 Oct 2019 15:00:07 -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 x94M00hT001381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Oct 2019 18:00:02 -0400
Date: Fri, 04 Oct 2019 14:59:59 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alissa Cooper <alissa@cooperw.in>
Cc: The IESG <iesg@ietf.org>, lake-chairs@ietf.org, lake@ietf.org
Message-ID: <20191004215959.GL6722@kduck.mit.edu>
References: <157006280821.8936.11952676534404855388.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <157006280821.8936.11952676534404855388.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/rypbWpPFMHGhm7BwZYeoto7-kPE>
Subject: Re: [Lake] Alissa Cooper's Block on charter-ietf-lake-00-00: (with BLOCK)
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: Fri, 04 Oct 2019 22:00:16 -0000

Hi Alissa,

Thanks for the close read.

On Wed, Oct 02, 2019 at 05:33:28PM -0700, Alissa Cooper via Datatracker wrote:
> Alissa Cooper has entered the following ballot position for
> charter-ietf-lake-00-00: Block
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lake/
> 
> 
> 
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
> 
> I have two questions I'd like to discuss before this goes out for external
> review:
> 
> 1. What are "the security properties expected of IETF protocols"? I think it
> would be fair to conclude that different protocols have different security
> properties. Is there a document to reference or some other way to convey what
> is meant by this?

This is probably my fault, as I suggested/added that line kind of at the
last minute.  Per
https://mailarchive.ietf.org/arch/msg/lake/3vXOjAUtkShaIhoAwzdnDAFlAkI ,
the idea is that "constrained" is not going to be an excuse to use bad
crypto, presumably in terms of the bit-strength of the confidentiality,
integrity, and authentication protections.  (I do note that we have quite a
bit of precedent for halving the integrity strength for IoT use to 64-bit
tags, but am not sure if I will come up with a good phrasing.)

> 2. I'm a little unclear on the interaction between the "at most one" language
> and the text about the TLS WG. If the TLS WG produces a LAKE that satisfies the
> requirements that the LAKE WG specifies, would that count as the "one"? Or
> might the TLS WG produce one and the LAKE WG produce one? Or is the TLS WG not
> expected to work on a LAKE?

It's fair to ask for clarity here: my sense is that "at most one" applies
to protocols that are the output of the LAKE WG.  If there's one (or more)
technologies from other WGs that meet the requirements as well as one being
produced by a LAKE WG, that's something we'll have to be able to address as
it arises.  My sense is that the WG will have spent a bunch of time
thinking about the problem space, so I'd ask the WG to make a qualitative
assessment of which technology to select for OSCORE, which could be (e.g.)
something from TLS or the "in-house" product.  I acknowledge that there may
be a bias towards the "in-house" product, but am confident that arguments
for and against diversity of available technology will be presented and
considered as the chairs determine consensus.

I'll note that TLS would (IMO) need a recharter to work on a LAKE, which
would most likely be to produce a modified form of TLS that is not subject
to the requirement that it *be* TLS (i.e., negotiates with previous
versions), allowing for a lot of redundancy and inefficiencies to be
removed.  Full de novo protocol work seems like it would fit better
elsewhere.

I'll work on some text to try to clarify these points (and add LWIG to the
related WG list; thanks Éric!).

Thanks,
Ben