Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

Göran Selander <> Sun, 24 March 2019 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D9EF120156 for <>; Sun, 24 Mar 2019 15:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.022
X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l7YEcgHyu4Yo for <>; Sun, 24 Mar 2019 15:08:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B22312014B for <>; Sun, 24 Mar 2019 15:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A5PQM4i8HRdwfKGsSyuMCQzI1PLmg3gf3Y/xVY8oFVY=; b=MoL/CpuHmfBisafCR+LUU5eFL1yyB43FQcmJhOqDjno6GEk5IHOn58biladqjgzb3KUg/YQtY9aSBkNqaaRD2wq5OzCqDB1Zq1s+ZrG1fwpbBWF+bWA3L2WYtvuPKjsSBY6BMIfDIpA1MgozLdGGu4Xf7Yyf7t/mquxYWzHytao=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Sun, 24 Mar 2019 22:08:10 +0000
Received: from ([fe80::2464:1071:5050:f397]) by ([fe80::2464:1071:5050:f397%2]) with mapi id 15.20.1750.014; Sun, 24 Mar 2019 22:08:10 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <>
To: "Pascal Thubert (pthubert)" <>, "" <>
Thread-Topic: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security
Thread-Index: AQHU4oDZ/DdlrW6JIEaAmirRY27M2g==
Date: Sun, 24 Mar 2019 22:08:10 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:67c:1232:144:344a:432d:ecb1:3f18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 262b5930-359b-4ba8-2746-08d6b0a5340c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3083;
x-ms-traffictypediagnostic: HE1PR07MB3083:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 09860C2161
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(136003)(376002)(39860400002)(199004)(189003)(71200400001)(82746002)(71190400001)(6306002)(2906002)(6246003)(105586002)(256004)(86362001)(15650500001)(83716004)(53936002)(14454004)(8676002)(106356001)(85202003)(85182001)(186003)(68736007)(5660300002)(66574012)(6512007)(14444005)(6116002)(476003)(6506007)(102836004)(305945005)(2616005)(7736002)(478600001)(8936002)(99286004)(966005)(413944005)(46003)(25786009)(316002)(486006)(33656002)(58126008)(97736004)(6436002)(81156014)(81166006)(2501003)(6486002)(36756003)(229853002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3083;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ZISgJjNuNklgKGhfLdPoWhIwoHxuogODSCP/yQLY2iTRiAx20cbqTKt0rUnnft1tpaKj9TxqZIK91ZzcTMBbK+cl6T69GqzZDk/USUZT24XFETy7rF1j7uOhjIq16YqP8qjh/k7FEJw8dF2+snjaNG6McCFG4YlaHaYwvAwbK/Q0WlY9gVsZiLMlN3grVYd0H17OPnz9+RpLV4ctZqnH2DUjf0k+X/+UzNoqdrIgRgjDQwFcpiwK+flUFawRSY5zXMcTdSwTzaTzXztptG5k2LSJALVrUJ6+Z5tHcXtxzMcfVcnZCSyMVGZzqJS+Uwl5+eJWRK0OC5UtTHc7oFi1CUMIwL+3D6+AV3cnHXjcpkL4PAU1s8kAqj4VnQpKF6a6NQNPeTrAcJGdI6XBqKALv+zlD4f04IVtemh7L4+EtUU=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 262b5930-359b-4ba8-2746-08d6b0a5340c
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2019 22:08:10.6986 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083
Archived-At: <>
Subject: Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security
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: Sun, 24 Mar 2019 22:08:19 -0000

Dear 6TiSCH,

Sorry for very late response, here are a some post-2nd WGLC comments on draft-ietf-6tisch-minimal-security-09:

Summary: With one exception detailed below the draft seems to be in good shape and essentially only need some harmonizing updates following the last changes to OSCORE which has now completed IESG review.

Main concern:

Section 8.3:
The recovery from complete failure of the JRC as currently described is not satisfactory and may lead to loss of confidentiality of data sent from the JRC to the pledge.  During reinitialization of pledges due to complete failure of JRC, the new JRC cannot detect replays of old initialization messages, nor does it know the latest sequence number used by the failed JRC: 
* It is not described how the new JRC reacts to a received CoJP request to avoid accepting a replay request or why it is not a problem with nonce reuse in the CoJP response.
* The procedure for the first Parameter Update with randomized payload may have different known CoAP header parameter values than the message with which nonce is reused, leading to a two-time pad which may to break confidentiality. It should at least be described why this is not an issue.
* There is no security consideration about properties of the encryption algorithm, in this case AES-CCM, which limits this attack to confidentiality.

There are different ways to resolve this. Here are two alternatives:

Appendix B.2 in OSCORE specifies a challenge-response based protocol for updating the security context based on an exchange of nonces. This protocol can be directly applied here where the replaced JRC in the role of CoAP server would trigger the protocol by responding to the reinitialization request with a new security context as is detailed in appendix B.2. The pledge then repeats the CoJP request with another security context and the JRC responds with the CoJP response using the agreed security context. In this way the old security context is replaced by a new, thereby removing the risks associated with accepting replayed messages and reusing nonces. 

The procedure in the previous paragraph does however not support the lightweight implementation option in Appendix B of this draft, since the master secret is needed for deriving the new security context. If this is very important to support, considering that CoJP is a special application of OSCORE it may be possible to specify a bespoke synchronization protocol. One setting for this is based on a reserved JRC sequence number for responses to reinitialization requests, the Echo option, and transport of the pledge record of last used JRC sequence number. This would require a careful analysis in particular of the use of JRC sequence numbers. 

A related concern is on the use of persistent memory: 

"In case of a reboot on either side, the retrieval of mutable security context parameters is feasible from the persistent memory such that there is no risk of AEAD nonce reuse due to a reinitialized Sender Sequence number, or of a replay attack due to the reinitialized replay window."

Section B.1.1 of OSCORE details some issues with writing to non-volatile memory that are applicable in particular to the JRC, and this text should be updated accordingly. Depending on the JRC implementation, this may be another reason why the pledges/joined nodes need to support the protocol in Appendix B.2 in the case of JRC losing context.

Minor concerns:
"Implementations MUST ensure that multiple CoAP requests to different JRCs are properly incrementing the sequence numbers "

I don't know why this is restricted to different JRCs: Implementations MUST ensure that multiple CoAP requests properly incrementing the sequence numbers.

"Since the pledge's OSCORE ID "

"Since the pledge's OSCORE Sender ID "

" A simple implementation technique is to instantiate the OSCORE security
   context with a given PSK only once and use it for all subsequent
   requests. "

Reference 7.5 and/or appendix B.1. Note that these are rewritten so references here may have changed (see below).

"The (6LBR) pledge and the JRC use the OSCORE security
   context parameters (e.g. sender and recipient identifiers) as they
   were used at the moment of context derivation, regardless of whether
   they currently act as a CoAP client or a CoAP server. "

I think this text is intended as a clarification of OSCORE functionality, but it doesn't make clear that that is what it is. Here is an attempt, perhaps you can do better:

Note that when the (6LBR) pledge and JRC changes roles between CoAP client and CoAP server, the same OSCORE security context as initially derived in each endpoint remains in use and the derived parameters are unchanged, for example Sender ID when sending and Recipient ID when receiving, see section 3.1 of [I-D.ietf-core-object-security].

"A technique that prevents reuse of sequence numbers,
   detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be
   implemented.  Each update of the OSCORE Replay Window MUST be written
   to persistent memory."

Section 7.5.1 is now B.1.1, and the procedure is slightly different, there are two parameters to set, K and F. Do you want to recommend any settings here?


On 2019-03-07, 15:45, "6tisch on behalf of Pascal Thubert (pthubert)" < on behalf of> wrote:

    Dear all:
    At the last IETF, we concluded the WGLC on draft-ietf-6tisch-minimal-security and concluded it was mostly ready. It received 7 reviews during the last WGLC, all of which had been integrated, and received reviewers approval.
    Two final changes were still needed.  Malisa was to discuss those on the ML, integrate them into a new version of the draft if consensus was found. There was in particular a dependency / alignlent to be made on OSCORE.
    More in <>. It appears that the issues are now resolved. Mališa, can you please summarize the status with OSCORE?
    As promised, the Chairs now open a 1-week WGLC on  focusing on those changes, though any bug you can find is good to mention too.
    The WGLC ends on Friday March 15th. Please have a good last look at the spec and let us know.
    Looking forward to meeting you all in Prague,
    The chairs