Re: [6tisch] Updates to minimal-security-06

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 24 March 2018 22:36 UTC

Return-Path: <mcr@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 2AEC5126DC2 for <6tisch@ietfa.amsl.com>; Sat, 24 Mar 2018 15:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.434
X-Spam-Level: *
X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no 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 MO5Zluu1W5EG for <6tisch@ietfa.amsl.com>; Sat, 24 Mar 2018 15:36:08 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A428012025C for <6tisch@ietf.org>; Sat, 24 Mar 2018 15:36:07 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [209.226.201.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 6AED61F95D; Sat, 24 Mar 2018 22:36:06 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6786414E0; Sat, 24 Mar 2018 22:36:00 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malishav@gmail.com>
cc: "6tisch@ietf.org" <6tisch@ietf.org>, "c.amsuess@energyharvesting.at" <c.amsuess@energyharvesting.at>
In-reply-to: <CANDGjyeuj0jv17jz2v-iEJd2oxY3Lq0CxBPkcJvSRzWqy_thpQ@mail.gmail.com>
References: <CANDGjydb27-u3r2vG5M6-mWj1fmin52Uq5qPu0d5n2OQsJQVyw@mail.gmail.com> <31648.1521740357@dooku.sandelman.ca> <CANDGjyeuj0jv17jz2v-iEJd2oxY3Lq0CxBPkcJvSRzWqy_thpQ@mail.gmail.com>
Comments: In-reply-to =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malishav@gmail.com> message dated "Fri, 23 Mar 2018 10:52:54 +0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sat, 24 Mar 2018 22:36:00 +0000
Message-ID: <14716.1521930960@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/PD_vkf5PSqF1fBN1JEpptFk2N9s>
Subject: Re: [6tisch] Updates to minimal-security-06
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 24 Mar 2018 22:36:09 -0000

Mališa Vučinić <malishav@gmail.com> wrote:
    mcr> I think that the mechanism that was explained at:
    mcr>   https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#
    mcr> section-4

    mcr> is a better workable solution.  Deploy all the new keys (it may take some
    mcr> days on sleep networks), and then have nodes switch when they see traffic
    mcr> with the new key.

    > Thanks, Michael, for the reminder on this document, I have to say that I forgot
    > about it.. IIUC, the issue you have with the mechanism I proposed is that the
    > JRC in some cases may not know how long it could take to deploy the keys so
    > that it cannot properly set the ASN. I think that's a valid concern and that it
    > would indeed be better if we could decouple the JRC from the inner network
    > specifics as much as possible.

Exactly.
It does not have to change significantly what you have, it just has to
include the (new) keyIndex.

    > To do this and support rekeying with your proposal, we need to differentiate
    > between "start using this key" and "install the key but don't start using it
    > until you see it being used in the network", for 6LBR and joined nodes to
    > follow, respectively. We can likely do this by extending the COSE_Key map with
    > an additional parameter for this purpose, which I prefer to pulling in the
    > whole COMI machinery, as is suggested in the minimal-rekey draft.

I agree, we don't need COMI, just the text about when to start using the new key.
Shall I suggest some text it github?

    > Essentially, the process would be: 
    > - the JRC deploys the new key(s) to all the nodes except to the 6LBR.
    > - nodes will install them, but keep using the old keys because the new COSE_Key
    > parameter is set to "install the key but don't start using it until you see it
    > being used in the network".

I'd say that you always do this with any new key if you have no keys.
I don't think we need a flag.

In fact, even for the "0th key", you would start using it as soon as you see
something that passes with that key, such as authenticating the Beacon that
you used to find the Proxy in the first place....

    > - deploy the key to the 6LBR, with the COSE_Key parameter set to "start using
    > now".
    > - once a node sees the new key being used and the replay protection and the
    > authenticity check at L2 passes, it removes the old keys and starts using the
    > new key for all outgoing traffic

Yes.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [