Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)

Qin Wu <bill.wu@huawei.com> Tue, 03 November 2020 13:32 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 6392E3A0A29 for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 05:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sT3JTypf7cgS for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 05:32:38 -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 C081C3A03FC for <iotops@ietf.org>; Tue, 3 Nov 2020 05:32:37 -0800 (PST)
Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3F352A5167E98BF56C04 for <iotops@ietf.org>; Tue, 3 Nov 2020 13:32:36 +0000 (GMT)
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) 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 13:32:35 +0000
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml710-chm.china.huawei.com (10.201.108.61) 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 13:32:35 +0000
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.33]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 21:32:29 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)
Thread-Index: Adax5R9hLGFGrosVQL6qCfn2q/r3rg==
Date: Tue, 03 Nov 2020 13:32:29 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADB1F8C6@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: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADB1F8C6dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/Ld-aTalnKyVeNYGcBgCCT84d2DE>
Subject: Re: [Iotops] maintain ownership (was: 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 13:32:39 -0000

On Sat, Oct 31, 2020 at 08:58:27AM +1300, Brian E Carpenter wrote:
> On 31-Oct-20 06:25, Michael Richardson wrote:
> >
> > Andrew G. Malis <agmalis@gmail.com<mailto: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.

Indeed, before even thinking about transferring ownership i would to see what
IETF security community can do to remove the current problem of even just
MAINTAINING OWNERSHIP in face of (if i am not mistaken) current PKI
recommendations:

My TivoHD for example had its certificate expire few years into its lifetime,
even though i had upfront bought a so-called "lifetime service" for it.
Of course, the lifetime-service did not include "maintaining a current cert for the
lifetime of the device".

And that is just the most egregious example i ran across because of me having
to learn how to hack up all the software that was talking to the TiVo via
TLS - to ignore the expired cert.

I am saying the IETF is partially to blame because i think we also proliferate
the notion that certificates have to be renewed periodically with maximum
usual lifetimes of now i think one year ? (was two years)

Of course, this is specifically a consumer-IoT problem, because industrial
customers should typically be in a stronger position to avoid these vendor
abuse of principally sound technical guidance.

As much as i like to explore short lived certificates more in environments
where i can set up the right environment to support that, we should IMHO
also think about the simplicity of lifetime-long-certificates. Which we
currently do not have in web PKI.

The fact alone that we do only have in browsers one single TA space (Internet)
seems to be the worst offender, proliferated by the fact that that is the
only domain that most big contributors in the IETF are interested in.
Nevertheless, to support what we classically did without crypto, namely
private networks (with private addresses), we should also have a crypto
strategy for such private networks. And in most cases, lifetime-long certs
will be the only reasonable solution there.

But, and to get back to the topic: One way on how to get to lifetime-long
certs would be an actual transfer of ownership from whaever the vendor
put in as certs to a cert from the current owner and using a lifelong
expiry time (e.g.: infinite). This could be hosted in a private TA.
The question is primarily how to have browsers support different TA
domains without confusing the user.

And of course, when you sell the device, you would need to do transfer
of ownership again by overwriting the current cert with one of the
new owner.
[Qin]: Not sure lifetime long certs is a good idea. I feel it is more vulnerable.
Also I think the current cert doesn't need to be overwritten by cert of the new owner.
The current Cert can be embedded in the Cert of new owner, see delegation voucher
https://tools.ietf.org/html/draft-richardson-anima-voucher-delegation-02
when the device is in resale, wrong?

JUst a line of thoughts.

Cheers
    Toerless