Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Yoav Nir <ynir.ietf@gmail.com> Sun, 19 January 2020 04:23 UTC

Return-Path: <ynir.ietf@gmail.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 7DCB0120041; Sat, 18 Jan 2020 20:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bUAbMw8HXyIU; Sat, 18 Jan 2020 20:23:27 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ED9120025; Sat, 18 Jan 2020 20:23:27 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id c14so26210019wrn.7; Sat, 18 Jan 2020 20:23:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sWZn+yDLv14eOPhOa62btO6jvKDsdo8AuCla/QEO9cY=; b=s7ew7IqflHDBP3RbyDlzExmdkAOkTGpJO0gvMchi1j+EsAeDeNIy8NFvsFGATqGGyO QEzoj8gsp/RrZKeO4FPySue0LfuyZHE+7kearK50yDvVhU34WlU+YZLIAHM4EVkiITBb UBkig7LYUKkhuAl80jPBwh2NJc5gawB+LwlwG5NL6c46ajSwzIRU74hEScGvFCoNS7im 5O6Yb2C/9Ygx4HHRofDrxWyVshXXVBXiwzlMcqe/KrEAuvrkJVB8PLe39sO5sJqzS3XF na6asCQmuplR7Au690MXhnKxEeWZv1SiE/GpnM2QeB5uFPhEY3WQrxm9IlkNjOfgDw/f jzRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sWZn+yDLv14eOPhOa62btO6jvKDsdo8AuCla/QEO9cY=; b=UAn0R0OBmn+jVYQSeNl8n17WM0WIx3hMun3KLRWjy2fcrfQV788TVB2pfHQD/qBDrf hkWX0DRtK+tZGScpgTdhJQxBvs5cNf2NPQgqHFJ+OhPcArofGBwRo/INv8ZAJsSpsvHJ +/8Ks2jgftPrxd3aDHD/smQIOrQ+ttfw6DPfon6wE1EKA9yjwvZ43qCqGUccq26L6Zcr f1GaCNx7b3t+PTZxyS4QuIpFKL0U2oA6GU21ntoT/z8Vdy8zndtRb5W4c2G+9vusGisr TMJMyYQ0f8H7R4Jou8J1nxzjhRSDPahBAupzarGFimgteux3sggw8/llCqJlTxNmSHSP nTAQ==
X-Gm-Message-State: APjAAAUZDlucsUkd3rodnIDoV4tTb/ZKJ40i/DLjuczsdjIp6x10DjEZ /C84StLoGXWW2KOpv+/ioWDqnWoi
X-Google-Smtp-Source: APXvYqxI68RYVGzmUCB8gui2KYumUtV97BVNCURTkmVOeZb9aQ04DGQacnm+RrBkNVatBw5eM5YNwQ==
X-Received: by 2002:adf:eb0a:: with SMTP id s10mr10980925wrn.320.1579407806080; Sat, 18 Jan 2020 20:23:26 -0800 (PST)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p17sm41387656wrx.20.2020.01.18.20.23.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 20:23:25 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <1093.1579301399@localhost>
Date: Sun, 19 Jan 2020 06:23:22 +0200
Cc: secdir <secdir@ietf.org>, last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <738E789C-14A8-41D5-956E-66E6CE2624DB@gmail.com>
References: <157919779948.26195.4879220696306890525@ietfa.amsl.com> <1093.1579301399@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/LdknLTbirK7Z3Vi51fTe5NA8rNI>
Subject: Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
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: Sun, 19 Jan 2020 04:23:29 -0000

Not really. You’ve added an explanation of why it’s hard to encrypt.  That is not needed IMO. What is needed is a statement that sending in the clear (not the default in IETF protocols these days) is OK because the data is not sensitive.

> On 18 Jan 2020, at 0:49, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Yoav Nir via Datatracker <noreply@ietf.org> wrote:
> 
>> The draft is short and to the point and easy to understand.  The security
>> considerations (and privacy considerations!) sections are well written and
>> cover everything.  I'm just missing one clause.
> 
>> The first paragraph reads:
>> All of the contents of this Information Element are sent in the
>> clear.  The containing Enhanced Beacon is not encrypted.
> 
>> What I'm missing is "...and this is fine because the 6tisch-Join-Info structure
>> contains no sensitive information."
> 
> point taken.  How do you feel about this:
> 
> # Security Considerations
> 
> All of the contents of this Information Element are sent in the clear.
> The containing Enhanced Beacon is not encrypted.
> This is a restriction in the cryptographic architecture of the TSCH
> mechanism.
> In order to decrypt or do integrity checking of layer-2 frames in TSCH, the
> TSCH Absolute Slot Number (ASN) is needed.
> The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes.
> 
> The Enhanced Beagon is authenticated at the layer-2 level using 802.15.4
> mechanisms using the network-wide keying material.  Nodes which are enrolled
> will have the network-wide keying material and can validate the beacon.
> 
> Pledges which have not yet enrolled are unable to authenticate the beacons,
> and will be forced to temporarily take the contents on trust.
> After enrollment, the pledge will be able to return to the beacon and
> validate it.
> 
> In addition to the enrollment and join information described in this
> document, the Enhanced Beacon contains a description of the TSCH schedule to
> be used by the transmitter of this packet.
> The schedule can provide an attacker with a list of channels and frequencies
> on which communication will occur.
> Knowledge of this can help an attacker to more efficiently jam
> communications, although there is future work being considered to make some
> of the schedule less visible.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>