Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 03 November 2020 19:01 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 2A2E13A0982 for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 11:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 LoRSPV9son4G for <iotops@ietfa.amsl.com>; Tue, 3 Nov 2020 11:01:27 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4133A3A0639 for <iotops@ietf.org>; Tue, 3 Nov 2020 11:01:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B40938983 for <iotops@ietf.org>; Tue, 3 Nov 2020 14:01:26 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d79ATRnh2u-7 for <iotops@ietf.org>; Tue, 3 Nov 2020 14:01:25 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 772273897F for <iotops@ietf.org>; Tue, 3 Nov 2020 14:01:25 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 659726A5 for <iotops@ietf.org>; Tue, 3 Nov 2020 14:01:25 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "iotops@ietf.org" <iotops@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADB1F8C6@dggeml511-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAADB1F8C6@dggeml511-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 03 Nov 2020 14:01:25 -0500
Message-ID: <15665.1604430085@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/r_IgC7DteS05TnHqbaRyiVUzTaM>
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 19:01:30 -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. Toerless => tte wrote: tte> Indeed, before even thinking about transferring ownership i would to see what tte> IETF security community can do to remove the current problem of even just tte> MAINTAINING OWNERSHIP in face of (if i am not mistaken) current PKI tte> recommendations: tte> My TivoHD for example had its certificate expire few years into its lifetime, tte> even though i had upfront bought a so-called "lifetime service" for it. tte> Of course, the lifetime-service did not include "maintaining a current cert for the tte> lifetime of the device". What did the certificate do? Was this part of an HTTPS management system, or did it allow it to connect back to some cloud service? tte> And that is just the most egregious example i ran across because of me having tte> to learn how to hack up all the software that was talking to the TiVo via tte> TLS - to ignore the expired cert. tte> I am saying the IETF is partially to blame because i think we also proliferate tte> the notion that certificates have to be renewed periodically with maximum tte> usual lifetimes of now i think one year ? (was two years) That's not the IETF making this policy, this is the CABForum.org, and this is driven mostly be browser manufacturer. All security is a circle. tte> Of course, this is specifically a consumer-IoT problem, because industrial tte> customers should typically be in a stronger position to avoid these vendor tte> abuse of principally sound technical guidance. You'd think so. The IETF can't really fix specific problems, but what we can do is provide names for processes that allow people/enterprises to take ownership of their devices. tte> The fact alone that we do only have in browsers one single TA space (Internet) tte> seems to be the worst offender, proliferated by the fact that that is the tte> only domain that most big contributors in the IETF are interested in. tte> Nevertheless, to support what we classically did without crypto, namely tte> private networks (with private addresses), we should also have a crypto tte> strategy for such private networks. And in most cases, lifetime-long certs tte> will be the only reasonable solution there. I am imagining a IoT-specific browser. It would have a different set of trust anchors. It would NEVER be able to talk to facebook or your bank. It would instead have a set of IoT trust anchors, and/or a federation of them. At this level, it can probably be done as a browser profile without changing much code. (The 382 day limit seems to not apply to additional trust anchors) Where we get into trouble, I think, is where you need to load content from multiple places. For instance, what if your device references jQuery from a CDN? What if you want to use OAUTH2 to login to your device as authorized by a cloud system? We don't have Cu (CoAP support)in Firefox anymore, because one can't write new schemes as extensions due to security architecture changes. tte> But, and to get back to the topic: One way on how to get to lifetime-long tte> certs would be an actual transfer of ownership from whaever the vendor tte> put in as certs to a cert from the current owner and using a lifelong tte> expiry time (e.g.: infinite). This could be hosted in a private TA. tte> The question is primarily how to have browsers support different TA tte> domains without confusing the user. I was thinking about this, and I come back to wondering if one thing that could be done is to have a completely different scheme for IoT devices. It would be "https", but with different rules about how it may reference other resources. To first order, COAPS does this, but not exactly. On my desktop, I use chrome for most things, but I use a specific firefox profile for banking and financial matters. I think that we need more of this: the various "incognito" moves go one direction (removing identity and interaction for certain transactions). We need another direction, super-cognito mode, where additional identity information is available. But, then we also need lateral movements, where I can substitute my "work" identity easily for my "home owner" identity. tte> And of course, when you sell the device, you would need to do transfer tte> of ownership again by overwriting the current cert with one of the tte> new owner. Qin Wu <bill.wu@huawei.com> wrote some comments: Qin> Not sure lifetime long certs is a good idea. I feel it is more Qin> vulnerable. Qin> Also I think the current cert doesn't need to be overwritten by cert Qin> of the new owner. The current Cert can be embedded in the Cert of new Qin> owner, see delegation voucher The delegation voucher provides a history of ownership. But, that isn't the device's certificate, it's the manufacturer's statement. I don't see how we can use delegated-voucher to augment the LDevID, except by replacing it. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Iotops] New Non-WG Mailing List: IOTOPS -- IOT O… IETF Secretariat
- Re: [Iotops] New Non-WG Mailing List: IOTOPS -- I… Andrew G. Malis
- [Iotops] can we create protocols that securely tr… Michael Richardson
- Re: [Iotops] can we create protocols that securel… Andrew G. Malis
- Re: [Iotops] can we create protocols that securel… Michael Richardson
- Re: [Iotops] can we create protocols that securel… Brian E Carpenter
- Re: [Iotops] maintain ownership (was: can we crea… Toerless Eckert
- Re: [Iotops] can we create protocols that securel… William_J_G Overington
- Re: [Iotops] can we create protocols that securel… Alexandre Petrescu
- Re: [Iotops] can we create protocols that securel… Michael Richardson
- Re: [Iotops] can we create protocols that securel… Michael Richardson
- Re: [Iotops] can we create protocols that securel… Toerless Eckert
- [Iotops] Use of abbreviations William_J_G Overington
- Re: [Iotops] Use of abbreviations Henk Birkholz
- Re: [Iotops] Use of abbreviations William_J_G Overington
- Re: [Iotops] Use of abbreviations Brian E Carpenter
- Re: [Iotops] can we create protocols that securel… Qin Wu
- Re: [Iotops] maintain ownership (was: can we crea… Qin Wu
- Re: [Iotops] maintain ownership (was: can we crea… Michael Richardson
- Re: [Iotops] maintain ownership (was: can we crea… Toerless Eckert
- Re: [Iotops] maintain ownership (was: can we crea… Toerless Eckert
- Re: [Iotops] maintain ownership (was: can we crea… Michael Richardson
- Re: [Iotops] maintain ownership (was: can we crea… Amyas Phillips, Ambotec
- Re: [Iotops] maintain ownership (was: can we crea… Michael Richardson
- Re: [Iotops] maintain ownership Brian E Carpenter
- Re: [Iotops] maintain ownership Michael Richardson
- Re: [Iotops] maintain ownership William_J_G Overington
- Re: [Iotops] maintain ownership William_J_G Overington