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

Mališa Vučinić <> Thu, 31 October 2019 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A81CD120071; Thu, 31 Oct 2019 10:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJD7GbP_6tow; Thu, 31 Oct 2019 10:53:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A6FE1200EC; Thu, 31 Oct 2019 10:53:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.68,252,1569276000"; d="scan'208,217";a="325272377"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2019 18:53:14 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7DA8D75-CAFE-4B56-8DBC-13BE977B28C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 31 Oct 2019 18:53:13 +0100
In-Reply-To: <>
Cc: The IESG <>,, Pascal Thubert <>, 6tisch-chairs <>,
To: Alvaro Retana <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2019 17:53:49 -0000

Dear Alvaro,

Many thanks for your review. I responded to your comments inline and you can find the proposed changes in the working version of the document at: <>

Please let me know if these changes sufficiently respond to your comments.


> On 30 Oct 2019, at 15:04, Alvaro Retana via Datatracker <> wrote:
> Alvaro Retana 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.

I think that there is a confusion here around the type of keys used. Keys that RFC8180 mentions in Section 4.6 are link-layer keys that according to that document can be either pre-configured or “learned during a key distribution phase”. The minimal-security document defines that key distribution phase through the Constrained Join Protocol (CoJP) and accompanying framework. In that context, RFC8180 specifies a more general case allowing for out-of-band configuration of link-layer keys, with the minimal-security document defining how to obtain the link-layer keys when they are not pre-configured. The minimal-security document is consequently written on the assumption that “pledge…initially…does not possess the link-layer keys”, but is provisioned with a long-term pre-shared key (PSK), used for encryption and authenticity of CoJP messages transporting the link-layer keys.

The text in RFC8180 is still valid so I do not believe there is a need for minimal-security to update that document. I added the following in Section 3 attempting to clarify the difference between the PSK and K1/K2 keys from RFC8180.

NEW: Note that the PSK is different from the link-layer keys K1 and K2 specified in {{RFC8180}}. The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document whose one output are link-layer keys.

Please let me know if this clarifies.

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

Thanks for the comment, I moved RFC7554, RFC8180 and IEEE802.15.4 to normative references.

> (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).

As Barry Leiba proposed in another review, I resolved this comment by removing the normative keywords and simply re-stating the requirement from RFC8180.

NEW: In an operational 6TiSCH network, all frames use link-layer frame security {{RFC8180}}. The IEEE Std 802.15.4 security attributes include frame authenticity, and optionally frame confidentiality (i.e. encryption).