Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

Christian Amsüss <christian@amsuess.com> Sat, 10 September 2022 10:31 UTC

Return-Path: <christian@amsuess.com>
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 C5A74C1522DA for <6tisch@ietfa.amsl.com>; Sat, 10 Sep 2022 03:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUmGSqaZus8C for <6tisch@ietfa.amsl.com>; Sat, 10 Sep 2022 03:31:02 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0B7C14F72C for <6tisch@ietf.org>; Sat, 10 Sep 2022 03:31:00 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 28AAUuJt057487 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Sep 2022 12:30:56 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B5FD4F129; Sat, 10 Sep 2022 12:30:55 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5D8F611832; Sat, 10 Sep 2022 12:30:55 +0200 (CEST)
Received: (nullmailer pid 1977906 invoked by uid 1000); Sat, 10 Sep 2022 10:30:54 -0000
Date: Sat, 10 Sep 2022 12:30:54 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: 6tisch@ietf.org, Michael Richardson <mcr@sandelman.ca>
Message-ID: <YxxnXvHE3WnCt/UO@hephaistos.amsuess.com>
References: <YUcakTFqibo5wEfe@hephaistos.amsuess.com> <102718.1632080924@dooku> <YUhQp3wQ6O3qXp6R@hephaistos.amsuess.com> <618FD3B4-2935-4D9E-9F96-B63454890B50@inria.fr> <YUhoXt7T8bLAU2gZ@hephaistos.amsuess.com> <E4FD542C-3751-4C15-8716-06F9C618C2F9@inria.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="X5NhLcSTStoeBf7F"
Content-Disposition: inline
In-Reply-To: <E4FD542C-3751-4C15-8716-06F9C618C2F9@inria.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/s4mf3PQiAndq2JPTOu_2VXcK8D8>
Subject: Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 10 Sep 2022 10:31:06 -0000

Hello Mališa,

(reviving the old thread because interest as sparked anew at the RIOT
summit, and Michael helped me see some alternatives)

my previous mails in this thread were focused around syncing time in
some different way. Maybe this is all not necessary -- as long as the
nodes themselves keep a counter which they never ever reset.

In particular, RF9030 states that "But if the nonce derives from the
short address [...] then the JRC must ensure that it never assigns short
addresses that were already given [...]. In other words, the network
must be rekeyed before the JRC runs out of short addresses." -- to me
that reads like the possibility is being considered that devices send
explicit frame counter. (For otherwise, reuse of a short address would
be fine as long as they're not assigned during the same ASN).

So before going on with questions about "how would any of this be
signaled", my question is:

* Do RFCs 9030/9031 allow that a device uses an explicit frame counter,
which it increments in its own pace?

  * If yes, shouldn't there be more stern words in 9031 about allowing a
    new key to be used with the same EUI-64 (considering that the device
    may not get a short identifier)?

    (Plus all concerns about the use of OSCORE Appendix B.2 or its
    replacement KUDOS would be relaxed, because if a device can use its
    own frame counter, it could use the same facilities to not lose its
    OSCORE sender sequence number).

  * If no, why the strict statement about rekeying before reuse of short
    identifiers?

I'd be happy with either answer, but it'd shape how and whether devices
that would explicitly use their own SSNs would communicate with the JRC.

Thanks
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom