Constrained Join Protocol (CoJP) for 6TiSCH
draft-ietf-6tisch-minimal-security-15

Summary: Has enough positions to pass.

Benjamin Kaduk (was Discuss) Yes

Comment (2019-12-09 for -14)
Thank you for addressing my Discuss and Comment points!
(Note that there is still ongoing email discussion of just a few
comment points from my previous ballot position.)

Suresh Krishnan Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-10-30 for -13)
** Section 3.  Per the definition of the PSK, the text says “The PSK SHOULD  be a cryptographically strong key, at least 128-bits in length, indistinguishable by feasible computation from a random uniform      string of the same length. 

-- Under what circumstances would a MUST not be more appropriate? (i.e., when would one want a cryptographically weak key)?

-- per the “128-bits in length” is that a statement about the actual numbers of bits in the key or a requirement for the key strength?

Section 8.4.2.  Per the “join rate”, how is the average data rate supposed to be calculated?

** Section 8.4.3.1.  Is it fair to say that how the JRC has determined “that the new key has been made available to all” is out of scope for this draft?  If so, it is worth saying explicitly.

** Section 8.4.4.1. Per “If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is eminent”, do you mean s/eminent/imminent/?  If not, could you please clarify what you mean here.

** Section 9.  Per “Many vendors are known to use unsafe practices when generating and provisioning PSKs.”, this is a strong statement (i.e., “many vendors”) to make without supporting evidence.  Either provide citation or weaken the sentence.

** Section 9, Per “As a reminder, recall the well-known problem with Bluetooth headsets with a "0000" pin.”, please provide a citation and short explanation.

Warren Kumari No Objection

Comment (2019-10-30 for -13)
I'm balloting NoObj because I trust Mirja, Barry to carry the DISCUSS (and Alvaro's good points too). Please also see the OpsDir review.

Mirja Kühlewind (was Discuss) No Objection

Comment (2019-12-05 for -14)
Thanks for addressing my discuss points and also other editorial comments! 

Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really good change!

And thanks for removing the Parameter Update Response message!

Barry Leiba (was Discuss) No Objection

Comment (2019-11-01 for -13)
Thanks for addressing my DISCUSS.

Alexey Melnikov No Objection

Comment (2019-10-31 for -13)
I agree with DISCUSSes from Adam and Barry. I think I agree with most of DISCUSS points from Mirja and Ben, but I reviewed them less attentively.

Alvaro Retana No Objection

Comment (2019-10-30 for -13)
I have a couple of important issues I want to bring up.  I don't think they raise to the level of a DISCUSS, but would like to talk about them before the document is published.

(1) What is the relationship between this document and rfc8180?  Both documents define "minimal" operation in a 6TiSCH network.  This document seems to build on rfc8180.  Should it formally Update it?  Should it also be a BCP?

One aspect that jumps at me is the fact that both documents declare key distribution/provisioning out of scope.  rfc8180 describes the behavior of a Joining Node (which I interpret to be the same as a pledge) "depending on which key(s) are pre-configured" (§4.6), but this document seems to assume only the case where the "pledge...initially...does not possess the link-layer key(s)" so that "during the join process, the pledge sends unencrypted and unauthenticated frames." (§5)  Leaving key distribution/provisioning out of scope is fine, but the assumptions of the operation are not congruent.  Given that rfc8180 is a BCP, then it seems that this document doesn't follow the Best Practices or maybe tries to update (?) them with this new minimal security framework.

(2) Normative References

§1: "This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]."  Why are these references not Normative?  If the content of this document is based on the descriptions in those RFCs, I believe they should be.

Also, IEEE802.15.4 seems to be important to understand in a 6TiSCH document.

(3) §5: The Normative keywords in this paragraph are out of place because the specification is already made in rfc8180.  IOW, there's no need to specify here what is already specified elsewhere.

   In an operational 6TiSCH network, all frames MUST use link-layer
   frame security [RFC8180].  The IEEE Std 802.15.4 security attributes
   MUST include frame authenticity, and MAY include frame
   confidentiality (i.e. encryption).

Adam Roach (was Discuss) No Objection

Comment (2019-12-05 for -14)
Thanks for addressing my DISCUSS and COMMENT points.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-10-31 for -13)
Thank you for the work put into this document. The document is easy to read. I have a couple of comments and nits. Feel free to ignore all of them.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Please add reference to IEEE Std 802.15.4 at first mention.

-- Section 1 --
It is unclear in this section whether the PSK is per pledge (then hitting a scalability issue) or shared by all pledge (then having huge security risk). Section 3 is clearer on this but the reader would benefit by knowing this in section 1.


-- Section 2 --
Please consider not using "secret key" and "symmetric key" interchangeably. Esp as "secret key" is often used in the context of asymmetric key.

-- Section 3 --
Unsure whether the text about provisionning "Physically, ..." brings anything useful.

-- Section 3 --
Please add references to DHCPv6, GRASP, mDNS.

-- Section 4.2 --
It is unclear whether duplicate address detection should be done.

== NITS ==

-- Section 4 --
Please expand L2 at first mention.

-- Section 6.1.2 --
I am not a native English speaker but I wonder whether the word 'convergecast' is well-known.

Magnus Westerlund No Record