Re: [Iotops] can we create protocols that securely transfer ownership?

Qin Wu <bill.wu@huawei.com> Tue, 03 November 2020 12:56 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB143A0966 for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 04:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Er_s0wejC51n for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 04:56:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84793A0965 for <iotops@ietf.org>; Tue, 3 Nov 2020 04:56:00 -0800 (PST)
Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3343D76565A8A003C6AA; Tue, 3 Nov 2020 12:55:59 +0000 (GMT)
Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 3 Nov 2020 12:55:59 +0000
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 3 Nov 2020 12:55:58 +0000
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.33]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 20:55:53 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "iotops@ietf.org" <iotops@ietf.org>
CC: Michael Richardson <mcr@sandelman.ca>
Thread-Topic: [Iotops] can we create protocols that securely transfer ownership?
Thread-Index: Adax3ztq9ZIaKul3Q9OMa0o+CJKXng==
Date: Tue, 03 Nov 2020 12:55:53 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADB1F88F@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.101.103]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/kw1TSxHC9_xm2WgiuiLxVYBD2gQ>
Subject: Re: [Iotops] can we create protocols that securely transfer ownership?
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 12:56:02 -0000

On 31-Oct-20 06:25, Michael Richardson wrote:
> 
> Andrew G. Malis <agmalis@gmail.com> wrote:
>     > Yes, in addition to being a good story, the point is who controls the
>     > firmware in our things, and how bad it can get not only when the
>     > manufacturer enforces DRM, but the gov't enables the behavior
>     > (criminalizing jailbreaking).
> 
>     > Or the issues that arise when the manufacturer fails to properly maintain
>     > the firmware, or goes out of business.
> 
> All major concerns.  What do you think the IETF can/should do?
> I have some very specific ideas which I think are manageable and specific.

Both BRSKI and SUIT have minor references to the latter problem, and I
think that when considering tiny cheap devices it isn't a theoretical issue,
but one that's highly likely. There is also (as for incandescent light
bulbs) a strong incentive for manufacturers to sell devices that are
designed to break after a while. An expiring certificate would be a great
way to break devices remotely, for example.

[Qin]: Indeed, if someone can tamper the clock and change system clock
Into one past time before the expiring date of the certificate, that means
the certificate duration is extended. How do we deal with this issue?

Similar issue is applicable to software license expiring.

   Brian