Re: [6tisch] rekeying the 6TiSCH network

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 20 August 2019 20:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143AE120A46 for <6tisch@ietfa.amsl.com>; Tue, 20 Aug 2019 13:03:15 -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 Sv2-VzKBSYeI for <6tisch@ietfa.amsl.com>; Tue, 20 Aug 2019 13:03:13 -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 2179912082E for <6tisch@ietf.org>; Tue, 20 Aug 2019 13:03:13 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 31506380BE; Tue, 20 Aug 2019 16:02:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 441DAF2A; Tue, 20 Aug 2019 16:03:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <malisa.vucinic@inria.fr>, Tero Kivinen <kivinen@iki.fi>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <MN2PR11MB356576EF7D90B7515043744DD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB356576EF7D90B7515043744DD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
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: Tue, 20 Aug 2019 16:03:12 -0400
Message-ID: <12588.1566331392@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/NTVkAJ4RaMv8RWQ6H-KUqaK4xjI>
Subject: Re: [6tisch] rekeying the 6TiSCH network
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 20:03:15 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > I'm looking for a consensus on how to address the following review
    > comment on the 6TiSCH Architecture by Benjamin:

    >> It would be good to see some architectural discussion about key
    >> management
    >> for the link-layer keys.  (Given that 802.15.4 leaves key management
    >> as out of
    >> scope, it is clearly our problem.)  Thus far I don't even have a sense
    >> for when it is
    >> possible to rotate a network's keys.

    PT> I'll take that to a separate thread with Michael, Tero and Malisa. It
    PT> is certainly possible to rotate keys. We had a draft about rekeying
    PT> that went stale. We isolated cases where this is desirable in the
    PT> discussion on the minimal security draft. I'm unclear how deep we
    PT> need to go in this regards vs. what belongs to the minimal security
    PT> specification.

6tisch-minimal-security has a section 8.2 "Parameter Update Exchange"
Maybe it should include "(and Rekey)"

We further have section 8.4.3.1 and 8.4.3.2 to explain how to use that
to rekey the entire network.

I'm not sure what's in the Architecture document about this, but I'd
rather that it just said less.

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