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
- [6tisch] Extending CoJP (minimal-security) for no… Christian Amsüss
- Re: [6tisch] Extending CoJP (minimal-security) fo… Michael Richardson
- Re: [6tisch] Extending CoJP (minimal-security) fo… Christian Amsüss
- Re: [6tisch] Extending CoJP (minimal-security) fo… Mališa Vučinić
- Re: [6tisch] Extending CoJP (minimal-security) fo… Christian Amsüss
- Re: [6tisch] Extending CoJP (minimal-security) fo… Mališa Vučinić
- Re: [6tisch] Extending CoJP (minimal-security) fo… Christian Amsüss
- Re: [6tisch] Extending CoJP (minimal-security) fo… Michael Richardson
- Re: [6tisch] Extending CoJP (minimal-security) fo… Tero Kivinen
- Re: [6tisch] Extending CoJP (minimal-security) fo… Mališa Vučinić