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

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 30 October 2019 21:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7161B120BC1; Wed, 30 Oct 2019 14:22:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6tisch-minimal-security@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, pthubert@cisco.com, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157247053545.32583.12074183717672805432.idtracker@ietfa.amsl.com>
Date: Wed, 30 Oct 2019 14:22:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/4JRrV301YVz-g_u5YIFAGSFAPNw>
Subject: [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
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: Wed, 30 Oct 2019 21:22:18 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-6tisch-minimal-security-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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