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

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>
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
Precedence: list

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>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>

[6tisch] Secdir last call review of draft-ietf-6t… Yoav Nir via Datatracker
Re: [6tisch] Secdir last call review of draft-iet… Prof. Diego Dujovne
Re: [6tisch] Secdir last call review of draft-iet… Michael Richardson
Re: [6tisch] Secdir last call review of draft-iet… Yoav Nir
Re: [6tisch] Secdir last call review of draft-iet… Michael Richardson
Re: [6tisch] Secdir last call review of draft-iet… Michael Richardson
Re: [6tisch] Secdir last call review of draft-iet… Pascal Thubert (pthubert)