Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 04 April 2019 14:04 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 1A3BF12067A; Thu, 4 Apr 2019 07:04:39 -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_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 jCRuW4yp9Cbw; Thu, 4 Apr 2019 07:04:34 -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 8BA5212069A; Thu, 4 Apr 2019 07:04:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 898C338275; Thu, 4 Apr 2019 10:03:40 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1D598D63; Thu, 4 Apr 2019 10:04:30 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1B403CBE; Thu, 4 Apr 2019 10:04:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Marco Tiloca <marco.tiloca@ri.se>, Malisa Vucinic <Malisa.Vucinic@inria.fr>
cc: 6tisch@ietf.org, draft-tiloca-6tisch-robust-scheduling@ietf.org
In-Reply-To: <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se>
References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se>
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: Thu, 04 Apr 2019 10:04:30 -0400
Message-ID: <8081.1554386670@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/JSvf3k5dZf58K2ice2vIwuPFR-E>
Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
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: Thu, 04 Apr 2019 14:04:39 -0000

Marco Tiloca <marco.tiloca@ri.se> wrote:
    >> A thought to deal with this is that the new permutation is not used
    >> until the node switches to the new keys.  EXCEPT that the adjacent
    >> nodes will now not be listening at the right time, won't hear traffic
    >> encrypted with the new key, and won't change over themselves.
    >> Authenticated enhanced beacons would perhaps help here.  Maybe I'm
    >> wrong about this problem.

    > <MT> This seems to deserve some more text in the Security
    > Considerations of Section 6.2, such as the following points.

    > The new link keys and permutation keys are expected to be distributed
    > together, just like for the described provisioning through the CoJP
    > Join Response, possibly through the same procedure described in [1].

yes, that's fine, but you have skipped the communications that will occur
*during* the rekey, when some nodes have new keys and some are still using
older keys.

I was looking for some text from 6tisch-minimal that explains how the rekey
actually occurs.

Malisa, it seems like this text has been lost.
Or did we move this process to another document?

The issue Marco is that use of the new key is signaled by receipt of a packet
that uses the new key.  The sending node will have already switched to a new
permuation, while the receiving node will still be on the old schedule.

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