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

From: Yoav Nir via Datatracker <[email-masked]>
Date: Thu, 16 Jan 2020 10:03:19 -0800

Reviewer: Yoav Nir
Review result: Has Nits

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."

I'm not disputing this or asking for rigorous proof, but it you say "this is
sent in the clear", you should finish with at least a statement that says that
this is OK.

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 16 Jan 2020 19:25:54 -0300

Yoav,
         Thank you for your feedback. I will add that line on the next
version.
Regards,

                                 Diego Dujovne

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 17:49:59 -0500

<#secure method=pgpmime mode=sign>

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Jan 2020 06:23:22 +0200

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 <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Jan 2020 12:16:21 -0500

Yoav Nir <[email-masked]> wrote:
    > 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.

No, I'm saying that it's architecturally impossible to encrypt.
It's not a choice.
Anything you plan to put into the beacon has to take this into account.

I take your point about explaining why the contents are not sensitive though.