IETF Logo Mail Archive

Re: [Lake] lake is now official, so...

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 23 October 2019 17:39 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 8C5FE120BE7 for <lake@ietfa.amsl.com>; Wed, 23 Oct 2019 10:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 i42f6bY6O2OT for <lake@ietfa.amsl.com>; Wed, 23 Oct 2019 10:39:44 -0700 (PDT)
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 A922E120971 for <lake@ietf.org>; Wed, 23 Oct 2019 10:39:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D61F83897C; Wed, 23 Oct 2019 13:37:08 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 28DFF76D; Wed, 23 Oct 2019 13:39:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: lake@ietf.org
CC: hallam@gmail.com
In-Reply-To: <957df1b8-c540-232c-5a50-3cd1ad011967@cs.tcd.ie>
References: <957df1b8-c540-232c-5a50-3cd1ad011967@cs.tcd.ie>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: Wed, 23 Oct 2019 13:39:43 -0400
Message-ID: <5736.1571852383@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/RBImWcvQSn65miKiTaYM5m-Yhlw>
Subject: Re: [Lake] lake is now official, so...
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: Wed, 23 Oct 2019 17:39:47 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    > I'd like to get a draft agenda for that sorted
    > in the next week, so please send any requests
    > for presentation slots or other agenda items.
    > Please say what you'd like to discuss and how
    > long you think that discussion may need.

Hi.

My requirements in draft-ietf-anima-constrained-voucher and
draft-ietf-6tisch-dtsecurity-zerotouch-join are for an AKE
that does:

1) RPK from server(network)->client(pledge)
2) certificate (IDevID) from client(pledge)->server(network)
3) identity protection of client's identity (IDevID)

This is hinted at in draft-selander-lake-reqs-02 section 2.4.2,
but the specifics above are not mentioned.  While some deployments might
prefer an entire certificate chain for (1), that chain can actually be
transfered after onboarding using a straight CORE block transfer.
That chain could also be transfered from an adjacent node in the mesh rather
than across the entire LLN.

I would welcome a mechanism that allowed the certificate to be sent by
reference rather than by value.  I would also like to be able to support
draft-birkholz-core-coid (both in-band and by reference) should it come to
fruition.

It appears that draft-hallambaker-mesh-udf-07 section 1.2.2
may facilitate this use, at 52 characters (in ascii) it is shorter. We can
probably do better by not base32 encoding, and making "udf://" implicit.

I don't know what we are going to with draft-selander-lake-reqs-02.
It would seem to fit into milestone 1, but it also seems like it is has
served that purpose already.

Stephen, if appropriate, I would be happy to further explain in a couple of
slides the requirements that come from 6tisch.  I would not put that very
high on the requirements for the WG, as this email is pretty much it.

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

v2.23.0 | Report a Bug | By Email