IETF Logo Mail Archive

Re: [Lake] Lake charter call for comments

Benjamin Kaduk <kaduk@mit.edu> Mon, 16 September 2019 16:47 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 26A2312004F for <lake@ietfa.amsl.com>; Mon, 16 Sep 2019 09:47:41 -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 xts3A3qgd5su for <lake@ietfa.amsl.com>; Mon, 16 Sep 2019 09:47:39 -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 17DDF120046 for <lake@ietf.org>; Mon, 16 Sep 2019 09:47:38 -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 x8GGlOPK027652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 12:47:26 -0400
Date: Mon, 16 Sep 2019 11:47:24 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Göran Selander <goran.selander@ericsson.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "lake@ietf.org" <lake@ietf.org>
Message-ID: <20190916164723.GL22210@kduck.mit.edu>
References: <20190904045654.GY58050@kduck.mit.edu> <D1F8429D-710A-4470-A8AC-4FF70AE56F97@akamai.com> <ADC3E3F3-E45C-430F-BC04-A3EEC68E8F43@ericsson.com> <03254E1C-4067-4994-8112-2A86E52D0EA0@akamai.com> <DFA5D43B-687B-43E5-AC3B-0C7D2D2C4E8E@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DFA5D43B-687B-43E5-AC3B-0C7D2D2C4E8E@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/-rWbp9Ca5rm57RXKrkYnKBULH0U>
Subject: Re: [Lake] Lake charter call for comments
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: Mon, 16 Sep 2019 16:47:41 -0000

On Tue, Sep 10, 2019 at 02:02:33PM +0000, Göran Selander wrote:
> 
> 
> > 10 sep. 2019 kl. 15:28 skrev Salz, Rich <rsalz@akamai.com>:
> > 
> > Thanks for the answer, it makes sense.
> > 
> > I still think a general statement like "without unnecessarily sacrificing security properties" should be there somewhere.  My intent behind that is that if the WG decides to use ROT13 because some IoT pencils have limited capabilities, this should be explained in the documents.
> > 
> > Does that make sense?
> > 
> 
> Indeed. The ambition of the various ongoing activities is to reduce overhead and simplify processing without sacrficing security. 

I could toss in a half-sentence (to crib Christian's phrasing) after the
list of what "lightweight" refers to: "but the LAKE must still provide the
security properties expected of IETF protocols".  How would that work?

Thanks,

Ben

v2.23.0 | Report a Bug | By Email