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@xxxxxxxxxxxx> wrote: > > > <#secure method=pgpmime mode=sign> > > Yoav Nir via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
