Re: [6tisch] TSCH and CCM security proofs

Tero Kivinen <kivinen@iki.fi> Wed, 17 July 2019 21:36 UTC

Return-Path: <kivinen@iki.fi>
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 D9E2E12011A for <6tisch@ietfa.amsl.com>; Wed, 17 Jul 2019 14:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 8VClmlo4Rdux for <6tisch@ietfa.amsl.com>; Wed, 17 Jul 2019 14:36:10 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FFC120116 for <6tisch@ietf.org>; Wed, 17 Jul 2019 14:36:10 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6HLZvpi003226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 00:35:57 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6HLZuZ3005481; Thu, 18 Jul 2019 00:35:56 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23855.38076.587920.287700@fireball.acr.fi>
Date: Thu, 18 Jul 2019 00:35:56 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <15268.1563217770@localhost>
References: <23846.23772.363888.302178@fireball.acr.fi> <MN2PR11MB3565CBB6A212C64388B3AA28D8F30@MN2PR11MB3565.namprd11.prod.outlook.com> <23847.46850.300632.27575@fireball.acr.fi> <15268.1563217770@localhost>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 5 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/NRA6f81IjIGjfz1V2J1uMSKF-4s>
Subject: Re: [6tisch] TSCH and CCM security proofs
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: Wed, 17 Jul 2019 21:36:12 -0000

Michael Richardson writes:
>     >   Implementations MUST use different L2 keys when using different MIC
>     > lengths, as using same key with different MIC lengths might be unsafe
>     > (i.e., using same key for both MIC-32 and MIC-64). See IEEE 802.15.4
>     > Annex B.4.3 for more information.
> 
> This seems like it isn't a problem.
> It would apply to network-wide keying only.

It applies all keys, not only network-wide keys. 

> While I guess we could include multiple Link_Layer_Key with the same
> key_id, and a different key_usage, that wasn't the intention.  I
> guess one could use a different K1 and K2 with a different MIC length, but
> have no idea why a network would want to mix MIC-32 and MIC-64.

Most common use might be someone using MIC-32 for beacons, but using
MIC-64 for actual data or something like that.
draft-ietf-6tisch-minimal-security seems to be using different keys
when the mic length is different (k1, and k2), and when k1 and k2 are
same it will always use same mic length, so there is no problem there.

Anyways it might good idea to add the warning somewhere, just incase
someone adds new combinations without realizing this problem.
-- 
kivinen@iki.fi