Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
Hello Michael I agree with the format you selected, things are readable this way. There are 2 or 3 typos in the new text that can be fixed with the editor. Also I’m happy with the conclusions you made on the possible attacks. All the best, Pascal > Le 22 janv. 2020 à 23:21, Michael Richardson a écrit : > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-6tisch-enrollment-enhanced-beacon-08=draft-ietf-6tisch-enrollment-enhanced-beacon-09 > > I have interspersed the security issues with each of the fields within the > description of the fields in section 2. This avoids enumerating the fields a > second time, and is probably more in the face for implementers. > This also makes it easier to review and avoids repeating what each field is. > > On the other hand, it may a poor way to present this. > > I am asking for the WG's opinion on whether to do it this way, or move it all > to the Security Considerations section. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
https://www.ietf.org/rfcdiff?url1=draft-ietf-6tisch-enrollment-enhanced-beacon-08=draft-ietf-6tisch-enrollment-enhanced-beacon-09 I have interspersed the security issues with each of the fields within the description of the fields in section 2. This avoids enumerating the fields a second time, and is probably more in the face for implementers. This also makes it easier to review and avoids repeating what each field is. On the other hand, it may a poor way to present this. I am asking for the WG's opinion on whether to do it this way, or move it all to the Security Considerations section. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
Yoav Nir 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
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 wrote: > > > <#secure method=pgpmime mode=sign> > > Yoav Nir via Datatracker 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 , Sandelman Software Works > -= IPv6 IoT consulting =- > > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
<#secure method=pgpmime mode=sign> Yoav Nir via Datatracker 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 , Sandelman Software Works -= IPv6 IoT consulting =- ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
Yoav, Thank you for your feedback. I will add that line on the next version. Regards, Diego Dujovne Le jeu. 16 janv. 2020 à 15:03, Yoav Nir via Datatracker a écrit : > 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. > > -- 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 ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
