Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2019 17:39:27 -0400

Roman Danyliw via Datatracker <[email-masked]> wrote:
    > ** 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?

changed to:

+ The PSK MUST be a cryptographically strong key, with at least 128 bits of
+ entropy, indistinguishable by feasible computation from a random uniform
+ string of the same length.

(The last part to keep people from using "0000")

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

added units, since it was == PROBING_RATE of RFC7252, the units of
byte/second are appropriate.
It's bytes/second sent from JP towards JRC.  I supposed we could specify
whether the L2/L3/L4 headers are counted or not, but I suspect that will wind
up in the error bar anyway.

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

It's not exactly out of scope.
The parameter update exchange (8.2) is used to update all the nodes.
The JRC knows who they are, because they joined, and the JRC gave them a
short-address.

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

fixed already in -13.

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

Malisa?

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

previously removed, but, I give you:
      title: "What is the default PIN on a bluetooth headset"
          "https://www.answers.com/Q/What_is_the_default_PIN_on_a_bluetooth_headset"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-