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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 01 November 2019 21:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70311200FE; Fri, 1 Nov 2019 14:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0AHrZxuA6Xf; Fri, 1 Nov 2019 14:39:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A5F120013; Fri, 1 Nov 2019 14:39:28 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F85A3818F; Fri, 1 Nov 2019 17:36:39 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5D4CB612; Fri, 1 Nov 2019 17:39:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>
cc: "The IESG" <iesg@ietf.org>, 6tisch-chairs@ietf.org, pthubert@cisco.com, draft-ietf-6tisch-minimal-security@ietf.org, 6tisch@ietf.org
In-Reply-To: <157247053545.32583.12074183717672805432.idtracker@ietfa.amsl.com>
References: <157247053545.32583.12074183717672805432.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Fri, 01 Nov 2019 17:39:27 -0400
Message-ID: <19584.1572644367@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/cmB4ISGxsn-tYJ16ICx3oTKEokY>
Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 21:39:31 -0000

Roman Danyliw via Datatracker <noreply@ietf.org> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-