[6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Yoav Nir via Datatracker <noreply@ietf.org> Thu, 16 January 2020 18:03 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 99570120071; Thu, 16 Jan 2020 10:03:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoav Nir via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <157919779948.26195.4879220696306890525@ietfa.amsl.com>
Date: Thu, 16 Jan 2020 10:03:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/OaUigJP7Nsp1mhBFOquxSd8gEXU>
Subject: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06
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: Thu, 16 Jan 2020 18:03:19 -0000

Reviewer: Yoav Nir
Review result: Has Nits

The draft is short and to the point and easy to understand.  The security
considerations (and privacy considerations!) sections are well written and
cover everything.  I'm just missing one clause.

The first paragraph reads:
   All of the contents of this Information Element are sent in the
   clear.  The containing Enhanced Beacon is not encrypted.

What I'm missing is "...and this is fine because the 6tisch-Join-Info structure
contains no sensitive information."

I'm not disputing this or asking for rigorous proof, but it you say "this is
sent in the clear", you should finish with at least a statement that says that
this is OK.