Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 05 December 2019 14:40 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 693EB120013; Thu, 5 Dec 2019 06:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 wb7wAlUyBs9E; Thu, 5 Dec 2019 06:40:09 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 3526A120019; Thu, 5 Dec 2019 06:40:08 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,281,1571695200"; d="scan'208";a="417895785"
Received: from wifi-eduroam-85-089.paris.inria.fr ([128.93.85.89]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2019 15:40:06 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
In-Reply-To: <a0133275-28b3-cdfa-2830-3f50265db1c9@sandelman.ca>
Date: Thu, 5 Dec 2019 15:40:06 +0100
Cc: 6tisch <6tisch@ietf.org>, The IESG <iesg@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, draft-ietf-6tisch-minimal-security@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B09767D6-B07E-4442-BBB7-77BC25BB4925@inria.fr>
References: <157250308434.32464.3300056120615958441.idtracker@ietfa.amsl.com> <a0133275-28b3-cdfa-2830-3f50265db1c9@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/aRXmNfFSyUeHk5Zgdq9JruU5vvg>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
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, 05 Dec 2019 14:40:11 -0000

Dear Ben,

We have just published a new version of the minimal-security document addressing, we believe, all your remarks. Would you mind checking it out, please?

Mališa

> On 19 Nov 2019, at 09:06, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> There are some seriously low-hanging fruit for traffic analysis with
>> some of these messages, e.g., any OSCORE request with 'kid' of "JRC" is
>> going to be a parameter update, at present.  If someone wanted to throw
>> out some chaff and muddle up this traffic analysis, what options are
>> available to them?
> 
> Any parameter Update Request occurs between the JRC and the already/previously on-boarded device.  So it occurs over the 802.15.4 L2 key(s).  It shouldn't visible against other CoAP traffic such as CoAP GET requests of sensor data.
> 
> There are three kinds of traffic that would be seen by a pervasive monitor:
> 
> 1) L2 traffic that is encrypted. It has a src/dst L2 address visible, which is probably an assigned 2-byte "short" address. (Which is assigned by this protocol.)
> 
> 2) Beacons that are authenticated but not encrypted.  Pledges can not authenticate the beacons as they haven't the right key (yet).  Others can, and this lets them sync to the schedule and update their ASN.
> They have an 8-byte source address.
> 
> 3) Join traffic which is not encrypted or authenticated, which has 8-byte source and 8-byte destinations, probably using vendor assigned EUI-64, but could be randomized EUIs.  ALL of this traffic is probably join traffic.  Yes, it is easily visible.
> 
> A PM can probably also guess which encrypted traffic relates to the join messages by a simple co-relation of message sizes, but that's not really that new.
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch