Minimal Security Framework for 6TiSCH

Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Benjamin Kaduk Discuss

Discuss (2019-10-30)
Thanks for this generally well-written document!  It does a great job at
making these fairly difficult topics accessible to the reader.  I have a
few points that should be fairly easy to address, but do need to be
addressed before the document should advance.

My comment on Section 8.4.4 tries to walk through some scenarios
involving a finite lease time on a short address; as a result of that I
think it's necessary to direct the 6LN to interpret the time in units of
ASN as opposed to wall-clock time.

The "parameter_addinfo" field in Unsupported_Parameter (Section 8.4.5)
feels underspecified to me.  The inline text says that only a subset of
the link-layer key set from the Configuration could be included here,
but how is that formally specified?

The string COJP_MAX_JOIN_ATTEMPTS appears only twice in the text, once
in Section 8.3.1 and again in the table in Section 8.5.  The former text
leaves me confused as to what counts as a "join attempt" for this
purpose, and in particular how it differs from the MAX_RETRANSMIT timer
mentioned in the previous sentence.

I couldn't find a clear statement that any node sending EBs needs to be
prepared to act as a join proxy; Section 4.1 notes that:
                  During the remainder of the join process, the node
   that has sent the EB to the pledge acts as the JP.
but I couldn't find where that was enforced.

I think we may need to say more about how a JP knows that "secExempt" is
in effect (see comment in Section 5), since that affects a critical
piece of the security posture of the network.

Finally, can we discuss whether a 32-bit MIC is the most appropriate
default for the key usage?  I lack the domain background to know how
much impact there is in going to an ENC-MIC64 or ENC-MIC128 scheme.
Comment (2019-10-30)
There are some seriously low-hanging fruit for traffic analysis with
some of these messages, e.g., any OSCORE request with 'kid' of "JRC" is
going to be a parameter update, at present.  If someone wanted to throw
out some chaff and muddle up this traffic analysis, what options are
available to them?


   secured by OSCORE.  This specification defines the Constrained Join
   Protocol and its CBOR (Concise Binary Object Representation) data
   structures, and configures the rest of the 6TiSCH communication stack
   for this join process to occur in a secure manner.  Additional

nit: this specification does not "configure the rest of the 6TiSCH
communication stack" directly; perhaps "describes how to configure" is
more appropriate.

Section 1

   This document defines a "secure join" solution for a new device,
   called "pledge", to securely join a 6TiSCH network.  The term "secure
   join" refers to network access authentication, authorization and
   parameter distribution, as defined in [I-D.ietf-6tisch-architecture].
   The Constrained Join Protocol (CoJP) defined in this document handles
   parameter distribution needed for a pledge to become a joined node.
   Authorization mechanisms are considered out of scope.  [...]

If "secure join" includes authorization, but authorization is out of
scope, does this document really define a "secure join" solution?

   [IEEE802.15.4].  The pledge then exchanges CoJP messages with the
   JRC; these messages can be forwarded by nodes already part of the
   6TiSCH network, called Join Proxies.  The messages exchanged allow

nit: I suggest rewording this, as the current wording suggests direct
pledge/JRC communication with subsequent forarding by proxies, whereas
reality is the other way around.

Section 2

   The term "6LBR" is used interchangeably with the term "DODAG root"
   defined in [RFC6550], assuming the two entities are co-located, as
   recommended by [I-D.ietf-6tisch-architecture].

nit: this wording seems to leave open the possibility that 6LBR and
DODAG root are not the same, which is allowed by the architecture
document even if discouraged, but does not tell the reader what happens
to this document's procedures in that case.  It might be easier to say
that this is "on the assumption that the two entities are co-located",
to make it more clear that this document does not apply to that case at

Section 3

   o  pledge identifier.  The pledge identifier identifies the (6LBR)
      pledge.  The pledge identifier MUST be unique in the set of all
      pledge identifiers managed by a JRC.  The pledge identifier

I recommend an explicit statement as to whether the pledge identifier is
used after the pledge becomes a joined node or only while a pledge.
(Noting that "while a pledge" does not have to be a contiguous single
block of time, of course.

      pledge MUST be provisioned with a unique PSK.  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.  How the PSK is generated and/or

[I agree with Roman -- when would the SHOULD be violated?]

   o  Pre-Shared Key (PSK).  A secret cryptographic key shared between
      the (6LBR) pledge and the JRC.  The JRC additionally needs to
      store the pledge identifier bound to the given PSK.  Each (6LBR)

The JRC also needs to be able to look up a PSK given a pledge
identifier, so perhaps it's better to describe the binding as going the
other way (or being bidirectional).

   o  Optionally, a network identifier.  The network identifier
      identifies the 6TiSCH network.  The network identifier MUST be
      carried within Enhanced Beacon (EB) frames.  Typically, the 16-bit

Isn't this an inherent property of EBs and not a new requirement for
minimal-security?  If so, the MUST may not be needed, in favor of
descriptive language.

   o  Optionally, any non-default algorithms.  The default algorithms
      are specified in Section 7.3.3.  When algorithm identifiers are
      not exchanged, the use of these default algorithms is implied.

nit: does this "exchanged" mean something other than the "provisioned"
that introduces this bulleted list?

Section 4

   2.  The pledge configures its link-local IPv6 address and advertises
       it to the JP using Neighbor Discovery.  This step may be omitted
       if the link-local address has been derived from a known unique
       interface identifier, such as an EUI-64 address.

Is it the configuring, the advertisement, or both, that is omitted when
derived from a known unique IID?

   As other nodes in the network, the 6LBR node may act as the JP.  The
   6LBR may in addition be co-located with the JRC.

nit: I think s/As/As for/

Section 4.1

   using the cells contained in the EB.  The pledge can hear multiple
   EBs; the selection of which EB to use is out of the scope for this
   document, and is discussed in [RFC7554].  Implementers should make

nit: This reads as a statement of fact, as if it will universally be
true that the pledge can hear multiple EBs.  I can suggest a specific
rewording if you want, though there should be several possibilities.

Section 4.2

   of the keys.  How JP accepts these unprotected frames is discussed in
   Section 5.

nit: "the JP".

Section 5

   When sending frames during the join process, the pledge sends
   unencrypted and unauthenticated frames.  The JP accepts these
   unsecured frames for the duration of the join process.  This behavior
   may be implemented by setting the "secExempt" attribute in the IEEE
   Std 802.15.4 security configuration tables.  How the JP learns
   whether the join process is ongoing is out of scope of this

This seems like a very important piece of information (whether the join
process is ongoing, i.e., whether to accept and process unauthenticated
frames).  Is it discussed in 802.15.4 or somewhere else?

   means of verifying the authenticity of EB frames.  As an attacker can
   craft a frame that looks like a legitimate EB frame, this opens up a
   DoS vector, as discussed in Section 9.

nit: this (first comma) is a comma splice.

Section 5.1

   the pledge.  The frames should be passed to the upper layer for
   processing using the promiscuous mode of [IEEE802.15.4] or another
   appropriate mechanism.  When the upper layer processing is completed
   and the link-layer keys are configured, the upper layer MUST trigger
   the security processing of the corresponding frame.  Once the

I suggest reiterating whether this upper-layer processing is happening
on the pledge or the JP.

Section 7.1

   This DoS vector on the JP can be mitigated by making the JP act as a
   stateless CoAP proxy, where "state" encompasses the information
   related individual pledges.  The JP can wrap the state it needs to

nit: "related to".

   This DoS vector on the JP can be mitigated by making the JP act as a
   stateless CoAP proxy, where "state" encompasses the information
   related individual pledges.  The JP can wrap the state it needs to
   keep for a given pledge throughout the network stack in a "state
   object" and include it as a CoAP token in the forwarded request to
   the JRC.  The JP may use the CoAP token as defined in [RFC7252], if
   the size of the serialized state object permits, or use the extended
   CoAP token defined in [I-D.ietf-core-stateless], to transport the
   state object.  The JRC MUST support extended token lengths, as
   defined in [I-D.ietf-core-stateless].  Since the CoAP token is echoed

Per [I-D.ietf-core-stateless], the (extended) token is hop-by-hop, so in
addition to the JRC needing to support extended tokens, isn't there in
practice a requirement that either no other proxying than join proxying
occurs or the proxies also support extended tokens?  (I assume this will
~always be the former, since we are expecting to do direct IPv6 from JP
to JRC.)

Section 7.3

   Implementations MUST ensure that multiple CoAP requests, including to
   different JRCs, are properly incrementing the sequence numbers, so
   that the same sequence number is never reused in distinct requests.

I suggest noting that this is also tied to the PSK that the pledge is
attempting to use to secure its communications with the JRC; the
sequence number space would be reset if a different PSK was provisioned
(as might happen if the device was transferred to a different network).

Section 7.3.1

   memory.  A technique that prevents reuse of sequence numbers,
   detailed in Appendix B.1.1 of [RFC8613], MUST be implemented.  Each
   update of the OSCORE Replay Window MUST be written to persistent

Just to check: is this mandating specifically the algorithm from
Appendix B.1.1 of RFC 8613 or just some algorithm to do so, of which the
referenced one is one example?

Section 8

   the case of 6LBR pledge.  The JRC may update the parameters at any
   time, by reaching out to the joined node that formerly acted as a
   (6LBR) pledge.  For example, network-wide rekeying can be implemented

nit: the use of the definite article "the" suggests that no parentheses
around "6LBR" were intended, but the next sentence suggests otherwise;
perhaps "the" is better as "a".

   This section specifies how the CoJP messages are mapped to CoAP and
   OSCORE, CBOR data structures carrying different parameters,
   transported within CoAP payload, and the parameter semantics and
   processing rules.

This sentence is pretty hard to parse.  What is the relationship amongst
the items in the comma-separated list?

Section 8.1.1

   Section 7.  If the CoAP at (6LBR) pledge declares the message
   transmission as failure, the (6LBR) pledge SHOULD attempt to join the

nit: I think the language used by RFC 7252 is not quite aligned with
this; if the max retransmissions are hit for a CON message, "the attempt
to transmit the message is canceled and the application process informed
of failure", so perhaps it's not the pledge doing so but rather the CoAP
stack thereupon.  (We do use language regarding the "CoAp
implementation" for the analogous situation in Section 8.2.1 already.)

   next advertised 6TiSCH network.  See Section 7.2 for recommended

nit: "next advertised" could be (mis)interpreted to mean "temporarlly
subsequent EB frame", disregarding all the discussion in Section 4.1
(and RFC 7554).

Section 8.2

Having every joined node act as a CoAP server on its "real" IPv6 address
and claiming the "/j" resource is definitely in conflict with BCP 190,
but let's cover this in Adam's ballot thread.

Section 8.3.1

   When a parameter that cannot be acted upon is encountered while
   processing a CoJP object in a CoAP response (Join Response message),
   a (6LBR) pledge SHOULD reattempt to join.  In this case, the (6LBR)

Is the assumption that the empty 2.04 of a Parameter Update Response
will never encounter an error condition in processing?

Section 8.3.3

   pledge generates locally.  After verifying the join request with the
   new ID Context and the derived OSCORE security context, the JRC
   should consequently take action in mapping the new ID Context with
   the previously used pledge identifier.  How JRC handles this mapping
   is implementation specific.

I understand that this does not need to be specified in this document,
but might there be a need for coordination between the JRC and the
pledge, e.g., to change the PSK between pledge and JRC?  (That would
make it "out of scope of this document" but not

   The described procedure is specified in Appendix B.2 of [RFC8613] and
   is RECOMMENDED in order to handle the failure events or any other
   event that may lead to the loss of mutable security context
   parameters.  The length of nonces exchanged using this procedure
   SHOULD be at least 8 bytes.

When would this SHOULD be violated?

Section 8.4.1

I do not see IANA registries for (e.g.) the join request 'role' values;
is there any chance that additional values might need to be allocated at
some point?

   Join_Request = {
       ? 1 : uint,                       ; role
       ? 5 : bstr,                       ; network identifier
       ? 8 : Unsupported_Configuration   ; unsupported configuration

"? 5 : bstr" does not seem consistent with the body text that mandates
inclusion of the network identifier.

Section 8.4.2

      contain at least one key.  When a pledge is joining for the first
      time and receives this parameter, before sending the first
      outgoing frame secured with a received key, the pledge needs to
      successfully complete the security processing of an incoming
      frame.  To do so, the pledge can wait to receive a new frame, or
      it can store an EB frame that it used to find the JP and use it
      for immediate security processing upon reception of the key set.

It might be interesting to have some discussion of how this relates to
the time verification discussion in Section 5.1.  (But maybe they're
totally unrelated and it wouldn't.)

      infinity SHOULD be assumed.  Node operating as a JP MAY use
      another mechanism that is out of scope of this specification to
      configure PROBING_RATE of CoAP in the absence of join rate
      parameter from the Configuration object.

nit: s/absence of/absence of a/

Section 8.4.3

   For encoding compactness, the Link_Layer_Key object is not enclosed
   in a top-level CBOR object.  Rather, it is transported as a sequence
   of CBOR elements, some being optional.

Is a reference to draft-ietf-cbor-sequence appropriate?

   o  key_addinfo: Additional information needed to configure the link-
      layer key, encoded as a byte string.  This parameter MAY be
      included.  The processing of this parameter is dependent on the
      link-layer technology in use and a particular keying mode.

Is the reference in the CoJP Key Usage registry going to be expected to
tell me anything I need to know to use key_addinfo, or some other

It seems like the indexing/assignment scheme for key usage values (e.g.,
in Table 3) is going to end up with something of a "combinatorial
explosion" of assignments, with a single codepoint indicating a
combination of five axes of parameters (link layer, cipher, k1 vs k2, k2
as encrypted vs.  authenticated-only, and size of auth tag).  Given the
expected pace of deployment of new algorithms, and the potential
expandability/range of CBOR integer encoding rules, it's probably
tolerable here, though.  I'm not sure how I feel about making a 32-bit
MIC the default, though.


   Sending of traffic with the new keys signals to other downstream
   nodes to switch to their new key, and the affect is that there is a

nit: s/affect/effect/

   ripple of key updates in outward concentric circles around each 6LBR.

nit: I suggest avoiding "circles" since the topology is unlikely to be
perfectly regular.


I might put a note in here that the contents/lengths of the
Link_Layer_Key fields serve to identify which 802.15.4 Key ID Mode to
use.  The example in Appendix A does make this pretty clear, but not
everyone is going to read the appendices.

      encoded first.  Which address is carried is determined from the
      length of the byte string.

nit: s/address/address type(s)/

   for example.  Pairwise keys could also be derived through a key
   agreement protocol executed between the peers directly, where the
   authentication is based on the symmetric cryptographic material
   provided to both peers by the JRC.  Such a protocol is out of scope
   of this specification.

Would there need to be a key_usage parameter that indicates to perform
such a pairwise key agreement protocol?

Section 8.4.4

I'd like to walk through the lease time with respect to the risk of
key+nonce reuse when a short ID is reassigned.  I see that the units are
given as hours here, but probably it's more relevant to think in terms
of timeslots, so that the lease time is a given number of timeslots
(dependent on the network's parameters, which are fixed constants).
Based on the ASN of the slot in which the CoJP parameters are received,
that means that the lease time specifies a range of ASNs for which this
node is allowed to use the short ID, and a compliant node will not use
the short ID with an ASN outside the range.  Even if the node powers off
and suffers realtime clock skew, when it starts listening again, a valid
EB will give it the current ASN and it will know whether the lease on
the short ID is still valid.  An attacker might replay an old valid) EB
in such a case and get the victim node to send traffic with an old ASN,
but I don't see a way for that to overlap (in terms of nonce reuse) with
any traffic sent by the subsequent recipient of a lease on that short
ID, since the new valid lease will cover a disjoint chunk of ASNs, and
so the nonce would not get reused by the different nodes.
On the other hand, if I relax this logic and have the node just trust
its real-time clock (without doing an ASN computation), then I think
there may be risk of the node going to sleep, suffering clock skew,
coming back online and re-learning the current ASN but erroneously
thinking that its lease is still valid (by wall-clock time) if it does
not do an ASN check.


   The JRC MUST ensure that at any given time there are never two same
   short identifiers being used under the same link-layer key.  If the

[as above, the "time" axis that is important is ASN, not wall-clock

Section 9

We should refer to the OSCORE security considerations as also being
relevant for CoJP.  I'm less sure whether we want to say something here
about the security properties of CoJP being dependent on the security
context between pledge and JRC, i.e., the PSK and use of persistent
storage for the mutable state in that security context, since that's
basically inherent to how OSCORE works.  Perhaps it's worth saying
something about how the pledge and JRC share a single security context
for the purpose of joining, and that this context is long-lived (i.e.,
the entire lifetime of the 6LN).

It's probably worth reiterating that while OSCORE provides replay
protection, it does not necessarily provide an indication of "freshness"
in the face of an attacker that can drop/reorder traffic.  We do mention
at least once that a misbehaving JRC could have precomputed a non-fresh
configuration response, and I might reiterate that here as well.  (That
could be relevant if, e.g., the JRC or its key information was
temporarily compromised and control subsequently regained by the
legitimate owner.)

Maybe it's more of an "operational considerations" note than a "security
considerations" one, but I suggest reiterating (e.g., in the second
paragraph) that there is substantial operational overhead in having a
unique PSK between pledge and JRC, but that it is vital to
the security properties of the network to do so.  (This has a fair
amount of overlap with what's already there, so I won't be very put out
if you decline to change anything.)

   The JP forwards the unauthenticated join traffic into the network.  A
   data cap on the JP prevents it from forwarding more traffic than the
   network can handle and enables throttling in case of an attack.  The

It's probably worth noting that this traffic can only be directed at the
JRC, and that the JRC needs to be prepared to handle such unsanitized
input [to a greater extent than ordinary 6LNs].

   Configuration object as it helps pledge fight a DoS attack.  These
   bogus beacons prolong the join time of the pledge, and so the time
   spent in "minimal" [RFC8180] duty cycle mode.  The blacklist
   communicated as part of the CoJP Configuration object helps JP fight
   a DoS attack by a malicious pledge.

nit: The "these" in "These bogus beacons" is probably too far removed
from the referent to be useful; I'd suggest avoiding the pronoun here.

Section 10

I think we should talk about the blacklist in the CoJP Configuration
object, since that's a vector for distributing some potentially
identifying information to a fairly broad audience from the JRC.
Hopefully it's only used for actually malicious nodes, which arguably
don't deserve much in the way of privacy, but it's possible that a more
mundane source of misbehavior could land a node on the blacklist, and I
want to be sure that we consider what the information content of the
blacklist is in that scenario.

   scanning and device-specific vulnerability exploitation.  Since the
   join process occurs rarely compared to the network lifetime, long-
   term threats that arise from using EUI-64 as the pledge identifier
   are minimal.  In addition, the Join Response message contains a short

I suspect I just failed to internalize things properly, but isn't the
pledge identifier used with the network IPv6 prefix to form the global
IPv6 address of the joined node?  So in that sense, using the EUI-64 as
the pledge ID transfers into the long-lived address and the privacy
threats are long-term as well.

   Once the join process completes, the new node uses the short
   addresses for all further layer 2 (and layer-3) operations.  This

My understanding is that this is the usual case but not strictly
required by any protocol spec.

   reduces the aforementioned privacy risks as the short layer-2 address
   (visible even when the network is encrypted) is not traceable between
   locations and does not disclose the manufacturer, as is the case of

Why is it not traceable between locations?

Section 11.1

It feels a little unusual to have a consolidate registry for CoJP
parameters that are used as map labels across different messages, without
some indication of which map labels are valid in which messages.

Section 13.2

I agree with Barry that RFC 8505 is probably more appropriately
categorized as a normative reference, and further suggest doing so for
draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869.

Appendix A

   Response to the correct pledge.  Note that the JP does not possess
   the key to decrypt the CBOR object (configuration) present in the

Nit: this is probably better described as a COSE or OSCORE object than a
CBOR one.

Appendix B

   the compromise of the entire batch.  When using the implementation/
   deployment scheme outlined above, the PSK does not need to be written
   to individual pledges.  As a consequence, even if a shared PSK is
   used, the scheme offers the same level of security as in the scenario
   where each pledge is provisioned with a unique PSK.

I'd be wary of describing this as "the same level of security", since
there does remain the latent risk that the shared PSK is compromised
from the provisioning device.  Something like "a comparable level" is
probably safer (ideally with an explanation of the risk of the PSK
leaking from the provisioning device).

Mirja Kühlewind Discuss

Discuss (2019-10-30)
1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this part is not sufficient:

Sec 6.1: "The Join Proxy implements a data cap on outgoing
   join traffic through CoAP's congestion control mechanism."

I think this needs an normative requirement here. Congestion control is supposed to avoid network overload but also to make use available resources. The congestion control as currently defined  for CoAP would probably limit the join traffic appropriately (to something like one packet per RTT likely) but CoAP could in theory use any time a different more aggrieve congestion and therefore just relying on congestion control generically doesn't seem to be sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that this can be achieved by congestion control as specified in the base CoAP spec. 
Further on there seems to be an implicit requirement that the JP MUST implement rate limit using the PROBING_RATE parameter, however, that is never explicitly spelled out as a normative requirement. However, if this rate is not provided by the JRC, it doesn't seem that any rate limiting has to be enforced. So maybe it would be good to be more strict here.

2) Also, not  sure if this editorial or a real issue but I'm not sure I fully understand this sentence:

Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
   forwarded should set it to zero so that it is compressed out."
If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. I guess it's not a big issue and setting to zero seems fine as well but I'm afraid I don't understand the intent here and when exactly the Proxy is supposed to set to AF43 or bleach.

3) This may also be mostly editorial but just to be sure: Section 7.2 provides default values for some of the CoAP transport parameter (where 2 of 3 are the same as defined in RFC7252) but not for all. Why is that?

4 ) And then finally on references (again):
Given that use of I-D.ietf-core-stateless is recommend, I believe it should be normative (and wait for publication of that doc).
Comment (2019-10-30)
I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all?

And some minor comments (mostly editorial proposals):

0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document title to make clear that this is a protocol spec and not "only" and abstract framework or something...

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED."
And then at the end of that paragraph: "This parameter MUST be provisioned to the 6LBR pledge."+

2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
"The JP operates as the application-layer proxy."
Maybe "... operates as an application-layer proxy" or probably even better "operates as application-layer proxy" ? Also at this part of the document it is not clear that the proxy actually interprets the CoAP message. I recommend to mention this earlier in the doc and maybe add a forward reference to section 7.

3) Sec 5: Maybe just to be absolutely clear:
OLD: "When sending frames during the join process, the pledge sends
   unencrypted and unauthenticated frames."
NEW: "When sending frames during the join process, the pledge sends
   unencrypted and unauthenticated frames at the link layer."

4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional
   network interface ..."
MAYBE: "As a special case, the 6LBR pledge may have an additional
   network interface ..." ?

Adam Roach Discuss

Discuss (2019-10-30)
Thanks to everyone who invested their time in this document. I have one
blocking comment that I believe should be easy to resolve, and one fairly major
comment that should be trivial to fix.


>  o  The Uri-Path option is set to "j".

COAP URIs are generally subject to BCP 190 restrictions, which would require
the path to either be provisioned, discovered, or under the ".well-known"
tree. The use of a reserved domain name here may change the rationale; but for
the sake of not establishing a precedent for path squatting in CoAP, this
document needs to clearly explain the rationale of why BCP 190 should not
apply in this case. Alternately, the implied URI can be changed to something
like "coap://"
Comment (2019-10-30)
>  This document allocates a well-known name under the .arpa name space
>  according to the rules given in [RFC3172].  The name "" is
>  requested.  No subdomains are expected.  No A, AAAA or PTR record is
>  requested.

Although "No subdomains are expected" is useful text, I don't think it's
sufficient to satisfy RFC 3172's requirements of specifying "the rules for how
the subdomain is administered." I would suggest something like:

"No subdomains are expected, and addition of any such subdomains requires
the publication of an IETF standards-track RFC."

Suresh Krishnan Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-10-30)
** 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  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 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)
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.

Barry Leiba (was Discuss) No Objection

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

Alexey Melnikov No Objection

Comment (2019-10-31)
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)
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).

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-10-31)
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.




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