Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 24 February 2020 19:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C03C83A116A for <lake@ietfa.amsl.com>; Mon, 24 Feb 2020 11:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ukFMXKHdf7IV for <lake@ietfa.amsl.com>; Mon, 24 Feb 2020 11:12:58 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED8C3A1168 for <lake@ietf.org>; Mon, 24 Feb 2020 11:12:58 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 88E6A38980; Mon, 24 Feb 2020 14:11:57 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 31EA75A4; Mon, 24 Feb 2020 14:12:57 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: "lake@ietf.org" <lake@ietf.org>
In-Reply-To: <b7c084b0-8489-5c05-046d-33aa70c85b94@cs.tcd.ie>
References: <b7c084b0-8489-5c05-046d-33aa70c85b94@cs.tcd.ie>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 24 Feb 2020 14:12:57 -0500
Message-ID: <1926.1582571577@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/lzdDSnq25sloVFMZ7FsPwYKcvlA>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01
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, 24 Feb 2020 19:13:01 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    > The authors have asked to start a WGLC for the requirements
    > document. [1] This mail is to start that. The deadline for
    > comments is March 19th in order to give the authors time to
    > prepare for discussion at the upcoming IETF meeting. Since

Hi, it is my understanding that we do not plan to publish this document, so I
guess maybe this is better called a WG Consensus Call?  :-)

I have read the document again from beginning to end today.
I haven't read Stephen's review yet.

In reading the AKE Frequency section a thought occured to me.
Is the NVRAM/storage requirement of the AKE important?
In the 6tisch zero-touch situation (including 6tisch-minimal-security, where
we do not use an AKE), there is a need to keep the resulting OSCORE context
alive long term because there is a need to rotate the network keys
(and sometimes the 2-byte address).
[ draft-ietf-6tisch-minimal-security-15 section 8.2 ]

That's just the infrastructure usage of OSCORE.
The device also performs some application, and that application may need one
or more contexts to remain "live" to continue.  I thought we had some text
somewhere about resumption as well.  I'm not sure what to do with this
thought, maybe this belongs in section 2.10?

Overall, the document is "good enough".

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-