From nobody Sun Nov 1 07:56:16 2020 Return-Path: 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 17DA73A0B2B for ; Sun, 1 Nov 2020 07:56:14 -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 iLkaLUYdBZie for ; Sun, 1 Nov 2020 07:56:12 -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 32C143A0B29 for ; Sun, 1 Nov 2020 07:56:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E9E6D389A7; Sun, 1 Nov 2020 11:03:07 -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 KjOquOeKSxdh; Sun, 1 Nov 2020 11:03:06 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CD6F389A3; Sun, 1 Nov 2020 11:03:06 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8AFBD1D2; Sun, 1 Nov 2020 10:56:08 -0500 (EST) From: Michael Richardson To: Alexandre Petrescu , iotops@ietf.org In-Reply-To: References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> <13731.1604075416@localhost> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 15:56:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexandre Petrescu wrote: > 'Transferring ownership' - like in selling property to somebody? A > contract would be needed, and a notary with an electronic signature. The notion of a third-party witness to attest to the transfer is definitely important. > In these worlds indeed the person-to-person communication would be > needed to avoid negative situations. But 'transferring ownership' wo= uld > not be desirable: one would not transfer ownership of information from > one's brain to Things and even less let these Things further > transfer ownership to other private interests. There would be a need= of > a protocol to make sure ownership is not transferred, but hardcoded in > silicium. I suspect that you don't understand the term, or that it didn't translate well for you. The point is when you sell your car to me, that it ceases to be your car, a= nd is now, only, my car. When you buy a house, the first thing you do is change all the locks. When you lease/rent a house, you don't. The landlord retains a copy of the= key. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+e2pgACgkQgItw+93Q 3WV3tAgArF9Prcso6F9WPVjvPQ2D/QnTAYT8TsCjjaXaaIbT0iCkFbEVbSH8DHmT rdT2AXiIPPRk04RwTFGYpeieQianNIs3S64cXTnigsFaboRvRPZ5H5dlvRByIUSa ACNiQgyNpkCXH+WafqYPvDqBBIAOh/UQJt7ThsbeFSXKYi5eMIrbj2CXpxtVYXTz qIXtY+4bPFpYfM7dOBibPaGPv9Rt41TJ0pxrsnkVUXyg2vxCfp7/jMlmA34qJk2d OcLWzZ3625E8UV8SMYVC9rY4lCkCBP0Zp2MZ7W49lyFtaptKLSUFoRmJrqiieAP7 ESUpZ15ECHwU20cAcQQ62dMnkuVYMw== =qL+S -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 1 08:00:35 2020 Return-Path: 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 E5C3B3A0B38 for ; Sun, 1 Nov 2020 08:00:32 -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 TOm6RKE2jWHy for ; Sun, 1 Nov 2020 08:00:30 -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 CDDD43A0B39 for ; Sun, 1 Nov 2020 08:00:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 160AF389A7; Sun, 1 Nov 2020 11:07: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 GfbRMNxx41NX; Sun, 1 Nov 2020 11:07:25 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DF9A389A3; Sun, 1 Nov 2020 11:07:25 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16B491D2; Sun, 1 Nov 2020 11:00:28 -0500 (EST) From: Michael Richardson To: William_J_G Overington , Iotops@ietf.org In-Reply-To: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 16:00:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable William_J_G Overington wrote: > I am wondering if the issue of being able to recover the original sof= tware > for a thing could be solved by some infrastructure something like it = being > good practice for the manufacturer of the thing to produce a hexadeci= mal dump > of the software and publish it in a PDF (Portable Document Format) do= cument > and for that PDF document to be deposited at The British Library in > accordance with the legal deposit regulations together with a note pe= rmitting > The British Library to supply a copy to anyone for a fee. The documen= t could > also be made available on the manufacturer's website, yet legal depos= it at > The British Library would mean that the document would still be avail= able > even if the manufacturer went out of business and the website was no = longer > available. While there is an issue of how to maintain software beyond the lifetime of the (interest of the marketing department) of the manufacturer, the bigger picture is that the device is cryptographically locked to running on softwa= re approved (digitally signed) by the manufacturer. We actually *need* this kind of lockdown in order to keep malware out. But, one person's weed is another person's wild-flower. Having the hexdump doesn't help us much. We basically already have that. Often we have the entire source code, but we still can't load it into the device because we don't have the keys that are baked (literally: by laser blown fuses into the silicon) into the device. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+e25sACgkQgItw+93Q 3WXd/Af/SwaPEjRAU/YNj/kLbToVHZVsdr2mJHvsY2vAFGidfwroT7RJi5rKlqiD P2W09U5W0LTu4Xmfs7yKR9VXEAHZRA9UG/4OYJHvgJmE/iTlnfzjJQMly5uZWHTo HSonarEOj6uHElGjrjZ6M8p3LtwVkRoFYXK0aSZMgPwF5y2mj4O05GgwlAm+dqbX LN6njnCQS15ez4QWe9vKcLTlDCo5l3SRWuVG6eiKMYpBCILJ5slV+UbaLMYmEFhu 7CNvKS5a/CAgFwqshpKZPx+W8ilT9ERm7yUW1Mi016wTr4qvkLx/QDJBzfvf4FQm Cr/UAnBWyESSxw2QA+uyn1NgZ8eNaA== =pERq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 1 08:51:36 2020 Return-Path: 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 021E63A0BFA for ; Sun, 1 Nov 2020 08:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TkGia2Z0kiJ1 for ; Sun, 1 Nov 2020 08:51:32 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE74F3A0BF5 for ; Sun, 1 Nov 2020 08:51:30 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4D2A454843F; Sun, 1 Nov 2020 17:51:25 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 486B1440059; Sun, 1 Nov 2020 17:51:25 +0100 (CET) Date: Sun, 1 Nov 2020 17:51:25 +0100 From: Toerless Eckert To: Michael Richardson Cc: William_J_G Overington , Iotops@ietf.org Message-ID: <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> <4838.1604246428@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4838.1604246428@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 16:51:34 -0000 On Sun, Nov 01, 2020 at 11:00:28AM -0500, Michael Richardson wrote: > While there is an issue of how to maintain software beyond the lifetime of > the (interest of the marketing department) of the manufacturer, the bigger > picture is that the device is cryptographically locked to running on software > approved (digitally signed) by the manufacturer. > > We actually *need* this kind of lockdown in order to keep malware out. > But, one person's weed is another person's wild-flower. Many ways to cut the cake: IMHO, devices MUST permit to override TA for secure boot/software with owner TA, so i can securely allow for it to only run software i as the owner sign. And those TA ultimately would be what identifies the owner. More so, then any certificate (because the TA designate who can do something with the device). In addition, i would want vouchers that sign with my own TA the cert of a vendor signed piece of software, so i can install such software. Most classical use-case: Do not permit arbitrary staff to install random vendor software versions, but only those that have been verified and approved by some testing department. And those vouchers might be short-lived, so that installation can only happen in a time window before a likely better updated software version would be preferrable. Or later downgrade without permission. > Having the hexdump doesn't help us much. We basically already have that. > Often we have the entire source code, but we still can't load it into the > device because we don't have the keys that are baked (literally: by laser > blown fuses into the silicon) into the device. Laser blown fuses sounds expensive. We had OTP memory forever. Cheers Toerless > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Mon Nov 2 00:03:27 2020 Return-Path: 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 D9F5C3A08C4 for ; Mon, 2 Nov 2020 00:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 4d5AN0zYQ_ra for ; Mon, 2 Nov 2020 00:03:24 -0800 (PST) Received: from rgout03.bt.lon5.cpcloud.co.uk (rgout0305.bt.lon5.cpcloud.co.uk [65.20.0.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97E3A005C for ; Mon, 2 Nov 2020 00:03:23 -0800 (PST) X-OWM-Source-IP: 10.110.12.1 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddttddgudduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefvkfgjfhfugggtfghihfffsegrtdersgdtreejnecuhfhrohhmpeghihhllhhirghmpgflpgfiucfqvhgvrhhinhhgthhonhcuoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeevleffieeivdelveelkefgkeetgeejleejteelledvffdvffdtveefudeuvedvgeenucfkphepuddtrdduuddtrdduvddruddpkeeirdduheekrdduledrfeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepfigvsghmrghilhegvddrsghtrdgvgihtrdgtphgtlhhouhgurdgtohdruhhkpdhinhgvthepuddtrdduuddtrdduvddruddpmhgrihhlfhhrohhmpeeofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoefkohhtohhpshesihgvthhfrdhorhhgqe Received: from webmail42.bt.ext.cpcloud.co.uk (10.110.12.1) by rgout03.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5D42B51907CDD5BF for Iotops@ietf.org; Mon, 2 Nov 2020 08:03:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604304203; bh=MgNQc9vA7xeyDUeGvDnSLzIHrYWA3rp1tgylFTXYvtI=; h=To:Message-ID:In-Reply-To:References:Subject:MIME-Version:From:Date; b=nVGrB3csFunwAsqCV+ayMxjIHhaqCzK9zxQV7r9hZ4prprZSYMjlC4A0mPEyV0hlExHcTKnUiu5ynvdGkUpATujHdCfydDwF9RC3lAsOuUgZrgYhtmlB2GjFSiKJ8bVc0+zw2Sc6Aqf5vJ8sdgHPHHJHcZTg6FRkrK0QjdBwBbM= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Mon, 2 Nov 2020 08:03:22 +0000 To: Iotops@ietf.org Message-ID: <51ef63e2.18a.17587fb6b8f.Webtop.229@btinternet.com> In-Reply-To: <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> <4838.1604246428@localhost> <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1636_857594520.1604304202538" User-Agent: OWM Mail 3 X-SID: 229 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Mon, 2 Nov 2020 08:03:22 +0000 (GMT) Archived-At: Subject: [Iotops] Use of abbreviations X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 08:03:26 -0000 ------=_Part_1636_857594520.1604304202538 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Could it be the custom and practice of this mailing list that upon first use of an abbreviation in a post that the meaning is stated in full please? Recently I had to look up OTP, I think I found the correct meaning but I am not congruently sure. I am still trying to find out what TA means. When, in another venue, I included mention of a PDF (Portable Document Format) document I was informed that readers would know what PDF meant. So it is a balance. My training was to always explain an acronym the first time one uses it, because some readers might not know the meaning of the acronym. So, I am retired, at home, just trying to take an interest and participate, I am not "at" an organization and I am "not representing an organization", but hopefully that is fine with the people who are "at" or are "representing an organization". William Overington Monday 2 November 2020 ------=_Part_1636_857594520.1604304202538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Could it be the custom and practice of this maili= ng list that upon first use of an abbreviation in a post that the meaning i= s stated in full please?

Recently I had to look up OTP, I think I = found the correct meaning but I am not congruently sure.

I am stil= l trying to find out what TA means.

When, in another venue, I incl= uded mention of a

PDF (Portable Document Format) document

I was informed that readers would know what PDF meant.

So it is a= balance. My training was to always explain an acronym the first time one u= ses it, because some readers might not know the meaning of the acronym.

So, I am retired, at home, just trying to take an interest and partic= ipate, I am not "at" an organization and I am "not represent= ing an organization", but hopefully that is fine with the people who a= re "at" or are "representing an organization".

William Overington

Monday 2 November 2020


------=_Part_1636_857594520.1604304202538-- From nobody Mon Nov 2 02:46:07 2020 Return-Path: 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 EEDD23A0DEC for ; Mon, 2 Nov 2020 02:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 kRUdZbI9jQFs for ; Mon, 2 Nov 2020 02:46:02 -0800 (PST) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 6DE9A3A0E9E for ; Mon, 2 Nov 2020 02:45:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G+EwAM459f/xwBYJligQmBUYRYhDO?= =?us-ascii?q?QbC6cKQsBAQEBAQEBAQEHAQEtAgQBAYRKAoIKASU5BQ0CEAEBBgEBAQEBBgQ?= =?us-ascii?q?CAoZahlABBQ4VDwEFLQkbCQIYAgImAgJHEAYBDAgBARiDCoJ8BZJJnAWBMoV?= =?us-ascii?q?XgzWBQoEOKoVTTkKGVw+BTT+BOA+CXD6HVYJfBJNgpBMrB4FigQ2BEAQLmVs?= =?us-ascii?q?FCh+DGIoRhRwGjx+TSpwOhDECBAIJAhWBbIF6TSRPgmpPFwINnGmBKwIGAQk?= =?us-ascii?q?BAQMJfIw7AYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2G+EwAM459f/xwBYJligQmBUYRYhDOQbC6cKQsBAQEBA?= =?us-ascii?q?QEBAQEHAQEtAgQBAYRKAoIKASU5BQ0CEAEBBgEBAQEBBgQCAoZahlABBQ4VD?= =?us-ascii?q?wEFLQkbCQIYAgImAgJHEAYBDAgBARiDCoJ8BZJJnAWBMoVXgzWBQoEOKoVTT?= =?us-ascii?q?kKGVw+BTT+BOA+CXD6HVYJfBJNgpBMrB4FigQ2BEAQLmVsFCh+DGIoRhRwGj?= =?us-ascii?q?x+TSpwOhDECBAIJAhWBbIF6TSRPgmpPFwINnGmBKwIGAQkBAQMJfIw7AYEQA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.77,444,1596492000"; d="scan'208";a="25389408" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 11:45:55 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRDQAM459f/1lIDI1igQmBUYIogUg?= =?us-ascii?q?wOIQzkGwunCkLAQMBAQEBAQcBAS0CBAEBhEoCgggCJTkFDQIQAQEFAQEBAgE?= =?us-ascii?q?GBHGFbYVzAQUOFQ8BBS0JGwkCGAICJgICRxAGAQwIAQEYgwqDAZJJnAWBMoV?= =?us-ascii?q?XgzWBQoEOKoVTTkKGVw+BTT+BOA+CXD6HVYJfBJNgpBMrB4FigQ2BEAQLmVs?= =?us-ascii?q?FCh+DGIoRhRwGjx+TSpwOhDECBAIJAhWBbCKBV00kT4JqTxcCDZxpQmkCBgE?= =?us-ascii?q?JAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,444,1596492000"; d="scan'208";a="38791148" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 11:45:53 +0100 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0A2Ajr00012239 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 2 Nov 2020 11:45:53 +0100 Received: from [192.168.16.50] (79.206.157.30) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 2 Nov 2020 11:45:48 +0100 To: William_J_G Overington , References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> <4838.1604246428@localhost> <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> <51ef63e2.18a.17587fb6b8f.Webtop.229@btinternet.com> From: Henk Birkholz Message-ID: <4eeec81c-67e8-dd7b-19dc-0a84722d32ce@sit.fraunhofer.de> Date: Mon, 2 Nov 2020 11:45:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <51ef63e2.18a.17587fb6b8f.Webtop.229@btinternet.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.157.30] Archived-At: Subject: Re: [Iotops] Use of abbreviations X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 10:46:06 -0000 Hello William, thank you for chiming in and speaking out. Sometimes conversations migrate to a place - hitting the road running - and that can make it more difficult to join such conversations. TA typically refers to a Trust Anchor in this context. That word is given a well-scoped meaning in RFC4949. Viele Grüße, Henk On 02.11.20 09:03, William_J_G Overington wrote: > Could it be the custom and practice of this mailing list that upon first > use of an abbreviation in a post that the meaning is stated in full please? > > Recently I had to look up OTP, I think I found the correct meaning but I > am not congruently sure. > > I am still trying to find out what TA means. > > When, in another venue, I included mention of a > > PDF (Portable Document Format) document > > I was informed that readers would know what PDF meant. > > So it is a balance. My training was to always explain an acronym the > first time one uses it, because some readers might not know the meaning > of the acronym. > > So, I am retired, at home, just trying to take an interest and > participate, I am not "at" an organization and I am "not representing an > organization", but hopefully that is fine with the people who are "at" > or are "representing an organization". > > William Overington > > Monday 2 November 2020 > > > > From nobody Mon Nov 2 04:38:58 2020 Return-Path: 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 56DB73A0EDB for ; Mon, 2 Nov 2020 04:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 0K-OJugxBtNv for ; Mon, 2 Nov 2020 04:38:55 -0800 (PST) Received: from rgout0804.bt.lon5.cpcloud.co.uk (rgout0804.bt.lon5.cpcloud.co.uk [65.20.0.151]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7D3A0EE6 for ; Mon, 2 Nov 2020 04:38:42 -0800 (PST) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddtuddggedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefvkfgjfhfugggtfghihfffsegrtdersgdtreejnecuhfhrohhmpeghihhllhhirghmpgflpgfiucfqvhgvrhhinhhgthhonhcuoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeejheelfedvfeekffduvefgkeehteffjeettdelteejgfehhffgheejudeutdeikeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutddruddutddruddvrddvpdekiedrudehkedrudelrdefjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeifvggsmhgrihhlvdeirdgsthdrvgigthdrtghptghlohhuugdrtghordhukhdpihhnvghtpedutddruddutddruddvrddvpdhmrghilhhfrhhomhepoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeokfhothhophhssehivghtfhdrohhrgheqpdhrtghpthhtohepoehhvghnkhdrsghirhhkhhholhiisehsihhtrdhfrhgruhhnhhhofhgvrhdruggvqe Received: from webmail26.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout08.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5BC47A8721B51F3D; Mon, 2 Nov 2020 12:38:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604320723; bh=e3URZbQIicIKnRZswVig0FZ2ADemqscmVuG4mkV9oRc=; h=To:Message-ID:In-Reply-To:References:Subject:MIME-Version:From:Date; b=IQdFHyEh1Zzs3UPp5Egf34UjoEbH1K0RSQIkRAn1sI/BGiRFrGBra2NlyxXoJyxEdNPs3sX3voI0XWQ64bvmoPZeYU/hkw5mW2GvvX0JVqLVtVjSjMKIZ0DDxnnJpzPLW8usNf7un5VcbkV1bg9II7b0HCwks/Mzn1bJaAkBQMM= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Mon, 2 Nov 2020 12:38:39 +0000 To: Henk Birkholz , Iotops@ietf.org Message-ID: <6236ffbd.676.17588f7729d.Webtop.217@btinternet.com> In-Reply-To: <4eeec81c-67e8-dd7b-19dc-0a84722d32ce@sit.fraunhofer.de> References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> <4838.1604246428@localhost> <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> <51ef63e2.18a.17587fb6b8f.Webtop.229@btinternet.com> <4eeec81c-67e8-dd7b-19dc-0a84722d32ce@sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9844_1026573788.1604320719417" User-Agent: OWM Mail 3 X-SID: 217 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Mon, 2 Nov 2020 12:38:39 +0000 (GMT) Archived-At: Subject: Re: [Iotops] Use of abbreviations X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 12:38:57 -0000 ------=_Part_9844_1026573788.1604320719417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Henk Thank you. Best regards, William ------ Original Message ------ From: "Henk Birkholz" To: "William_J_G Overington"=20 ; Iotops@ietf.org Sent: Monday, 2020 Nov 2 At 10:45 Subject: Re: [Iotops] Use of abbreviations Hello William, thank you for chiming in and speaking out. Sometimes conversations=20 migrate to a place - hitting the road running - and that can make it=20 more difficult to join such conversations. TA typically refers to a Trust Anchor in this context. That word is=20 given a well-scoped meaning in RFC4949. Viele Gr=C3=BC=C3=9Fe, Henk On 02.11.20 09:03, William_J_G Overington wrote: Could it be the custom and practice of this mailing list that upon first=20 use of an abbreviation in a post that the meaning is stated in full=20 please? Recently I had to look up OTP, I think I found the correct meaning but I=20 am not congruently sure. I am still trying to find out what TA means. When, in another venue, I included mention of a PDF (Portable Document Format) document I was informed that readers would know what PDF meant. So it is a balance. My training was to always explain an acronym the=20 first time one uses it, because some readers might not know the meaning=20 of the acronym. So, I am retired, at home, just trying to take an interest and=20 participate, I am not "at" an organization and I am "not representing an=20 organization", but hopefully that is fine with the people who are "at"=20 or are "representing an organization". William Overington Monday 2 November 2020 --=20 Iotops mailing list Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops=20 ------=_Part_9844_1026573788.1604320719417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Henk


Thank you.


Best regards,


<= p>William





------= Original Message ------
From: "Henk Birkholz" <henk.birkho= lz@sit.fraunhofer.de>
To: "William_J_G Overington" <wjgo= _10009=3D40btinternet.com@dmarc.ietf.org>; Iotops@ietf.org
Sent: Mond= ay, 2020 Nov 2 At 10:45
Subject: Re: [Iotops] Use of abbreviations
Hello William,



thank you for chiming in and speaking out= . Sometimes conversations migrate to a place - hitting the road running - a= nd that can make it more difficult to join such conversations.


=
TA typically refers to a Trust Anchor in this context. That word is gi= ven a well-scoped meaning in RFC4949.





Viele Gr=C3= =BC=C3=9Fe,



Henk



On 02.11.20 09:03, Willi= am_J_G Overington wrote:

<= td width=3D"3">
Could it be the custom and practice of this mailing= list that upon first use of an abbreviation in a post that the meaning is = stated in full please?



Recently I had to look up OTP, I th= ink I found the correct meaning but I am not congruently sure.


=
I am still trying to find out what TA means.



When, in= another venue, I included mention of a



PDF (Portable Docu= ment Format) document



I was informed that readers would kn= ow what PDF meant.



So it is a balance. My training was to = always explain an acronym the first time one uses it, because some readers = might not know the meaning of the acronym.



So, I am retire= d, at home, just trying to take an interest and participate, I am not "= ;at" an organization and I am "not representing an organization&q= uot;, but hopefully that is fine with the people who are "at" or = are "representing an organization".



William Over= ington



Monday 2 November 2020










--

Iotops maili= ng list

Iotops@ietf.org

https://www.ietf.org/mailman/listinfo/iotops

------=_Part_9844_1026573788.1604320719417-- From nobody Mon Nov 2 05:15:05 2020 Return-Path: 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 C194F3A1107 for ; Mon, 2 Nov 2020 05:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 Yu9fGQRFEa9i for ; Mon, 2 Nov 2020 05:14:55 -0800 (PST) Received: from rgout02.bt.lon5.cpcloud.co.uk (rgout0206.bt.lon5.cpcloud.co.uk [65.20.0.205]) by ietfa.amsl.com (Postfix) with ESMTP id 940313A106E for ; Mon, 2 Nov 2020 05:14:42 -0800 (PST) X-OWM-Source-IP: 10.110.13.1 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddtuddggeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepvffkufggtggfihfhffesrgdtregstderjeenucfhrhhomhephghilhhlihgrmhgplfgpifcuqfhvvghrihhnghhtohhnuceofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepkedvudegvdefffeghfdtueejgeefhfegjeekhfehtdduveefjeevheeiudfguddunecuffhomhgrihhnpehglhhosggrlhhnvghtrdgtohdruhhknecukfhppedutddruddutddrudefrddupdekiedrudehkedrudelrdefjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeifvggsmhgrihhlvdeirdgsthdrvgigthdrtghptghlohhuugdrtghordhukhdpihhnvghtpedutddruddutddrudefrddupdhmrghilhhfrhhomhepoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeokfhothhophhssehivghtfhdrohhrgheq Received: from webmail26.bt.ext.cpcloud.co.uk (10.110.13.1) by rgout02.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5B93D59426477EC7 for Iotops@ietf.org; Mon, 2 Nov 2020 13:14:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604322882; bh=qCJWWFJe+nmAD/hryBZwVJFJ68XmgRWkjJz8ur4WCio=; h=To:Message-ID:Subject:MIME-Version:From:Date; b=h3y+VrD2JhipgPJ/oMalqelNCR+VRggf1k9BUpsWxUGxmFsyUUGlKe2wbBEmm9nV8rkf9qH5Z0hBAbFUxUFcKxshGLybZNvqNZr1/wrPKoAZ6a/l3GfSM/Uwc3pvO+VSz0cedMjJVkj9NX+v9PQyyKLXc3miKeg7jf8zuFki+Gg= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Mon, 2 Nov 2020 13:14:32 +0000 To: Iotops@ietf.org Message-ID: <2ba024a8.710.17589184df3.Webtop.217@btinternet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11070_1589557078.1604322872745" User-Agent: OWM Mail 3 X-SID: 217 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Mon, 2 Nov 2020 13:14:32 +0000 (GMT) Archived-At: Subject: [Iotops] Could a device with an email address, a password and a FORTH-like langauge interpreter be of use in The Internet of Things? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 13:15:03 -0000 ------=_Part_11070_1589557078.1604322872745 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I am wondering if one could have an Internet of Things thing that includes on a printed document inside the sealed box that contains the thing when bought.an email address and a password. A person who knows the email address of the device could then send an email to the thing and get a reply by email. As a basic example the thing could have a thermometer and respond to an email enquiry as to the temperature. Some devices could have other facilities. A person who knows both the email address and the password of the device can send it emails that are acted upon because the thing has built-in to it an open source software system, a modern updated version of a FORTH-like language interpreter. This would include the ability to program commands that anyone who knows the email address of the thing could then use. I first met the FORTH language (the name is apparently because it was the FOURTH version of something, but the computer system upon which it was first implemented only allowed five-letter file names, all capitals).in a hobbyist computer magazine in the 1980s. I wrote a small cut-down version of FORTH for use on a mainframe computer for the experience - I either programmed it in FORTRAN or Pascal, I do not remember which. I mentioned a modern updated version of a FORTH-like language. FORTH was not typed. Some experiments that I carried out starting in 2000 were for a highly-typed FORTH-like language - there were float, integer, complex, quaternion, character and string types. http://www.users.globalnet.co.uk/~ngo/14560000.htm Thus the device would be under the complete ownership of whoever bought it in and could be programmed to do what is wanted by the owner within the limits of the capabilities of the thing, such as whether it measures temperature or moves a camera around and takes photographs or whatever. Do such devices already exist, could they exist, is it a good idea? William Overington Monday 2 November 2020 ------=_Part_11070_1589557078.1604322872745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am wondering if one could have an Internet of T= hings thing that includes on a printed document inside the sealed box that = contains the thing when bought.an email address and a password.

A = person who knows the email address of the device could then send an email t= o the thing and get a reply by email.

As a basic example the thing= could have a thermometer and respond to an email enquiry as to the tempera= ture. Some devices could have other facilities.

A person who knows= both the email address and the password of the device can send it emails t= hat are acted upon because the thing has built-in to it an open source soft= ware system, a modern updated version of a FORTH-like language interpreter.=

This would include the ability to program commands that anyone wh= o knows the email address of the thing could then use.

I first met= the FORTH language (the name is apparently because it was the FOURTH versi= on of something, but the computer system upon which it was first implemente= d only allowed five-letter file names, all capitals).in a hobbyist computer= magazine in the 1980s. I wrote a small cut-down version of FORTH for use o= n a mainframe computer for the experience - I either programmed it in FORTR= AN or Pascal, I do not remember which.

I mentioned a modern update= d version of a FORTH-like language.

FORTH was not typed.

= Some experiments that I carried out starting in 2000 were for a highly-type= d FORTH-like language - there were float, integer, complex, quaternion, cha= racter and string types.

http://www.users.globalnet.co.uk/~ngo/145= 60000.htm

Thus the device would be under the complete ownership of= whoever bought it in and could be programmed to do what is wanted by the o= wner within the limits of the capabilities of the thing, such as whether it= measures temperature or moves a camera around and takes photographs or wha= tever.

Do such devices alr= eady exist, could they exist, is it a good idea?

William Ov= erington

Monday 2 November 2020

<= /html> ------=_Part_11070_1589557078.1604322872745-- From nobody Mon Nov 2 11:45:40 2020 Return-Path: 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 997533A1014 for ; Mon, 2 Nov 2020 11:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 A5wQxM7ABwTs for ; Mon, 2 Nov 2020 11:45:38 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AB73A0FB3 for ; Mon, 2 Nov 2020 11:45:19 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id o3so11663845pgr.11 for ; Mon, 02 Nov 2020 11:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6+W/aWBJauEcTm/aER8zJLF4F//xWQynibpw+qUI7ME=; b=PEv2oh1LJtQqPST2ebUprq+VZw8MNEeu6/VpX33jO+A+4f0iwhXwTVG+1HkY8iupDq EtFzi3YVOb6vuzaNjmzMia53AAMfJPGX3zxOWEhDJ4WzGiJO4on0rZBzN+/LW6IZDKOF gz19J5Mc0ixImhahS/R1vM9SP9MxIw7/b3UzYGebAtn672dDDUJggaACiHpBYq/vSU9y FeZbx9EqqMU1hSDNvFI+DPEjI1CfOaFGJflQaQqi1UNqNIKqN0XV+viy0JQ8fKyIU7A4 yRhxs9cAjkCc18r3H6u77g7IojCdGr/4qYVV7eLtpo+fzy938ZX8VmWBbW1ZM9+7KzbB 0Png== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6+W/aWBJauEcTm/aER8zJLF4F//xWQynibpw+qUI7ME=; b=m9ISU7kV2LLu+R2kSn5v/45JGmtZoXfLhejEQB9S+Gq/uGkkqEtqfgi68Z7WRbNUSf EeH/RXMmnwDZ07Sitnmp4ek4M+dp9Z8whg2rU06A+offM1jn7z41lum7NqO8zAIkSOcm kPD0/WN7prl7ZA7xeD6I0+Ub5BuqK1oJ8xo4SWxXNvhuq6LuESS9tjuMECcu7xPZC77u djJCVvBTzg+RreDntR3vVbGjrnSwjSbJeo+V2YAj7wxqUHStEOv2sExW56DSBDrHD/2D dYqYJNq1C2KIHFBJhLbbyV41DI5g5RRZKezgCVvv7zJW4Pix/u9J6olCxRBRsLCS/CSR Jw+g== X-Gm-Message-State: AOAM533IFs1pBzTm3PqQ+lLmsKB14Vyb+Jhq+eB6mwQdq0evgz5nE5wV 9B+QcKjsLyIhNzSg6zihyWF4wiHpcRsGgA== X-Google-Smtp-Source: ABdhPJzwOnBGs68OhYR1C7nK6I+fs3ld7+F5KznX92jhT/PbQhmrqOWxi7ZYCBecwv/WYwuVeokOmA== X-Received: by 2002:a17:90a:c48:: with SMTP id u8mr19050415pje.121.1604346318111; Mon, 02 Nov 2020 11:45:18 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id b17sm13277624pgb.94.2020.11.02.11.45.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 11:45:17 -0800 (PST) To: William_J_G Overington , Henk Birkholz , Iotops@ietf.org References: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> <4838.1604246428@localhost> <20201101165125.GQ48111@faui48f.informatik.uni-erlangen.de> <51ef63e2.18a.17587fb6b8f.Webtop.229@btinternet.com> <4eeec81c-67e8-dd7b-19dc-0a84722d32ce@sit.fraunhofer.de> <6236ffbd.676.17588f7729d.Webtop.217@btinternet.com> From: Brian E Carpenter Message-ID: Date: Tue, 3 Nov 2020 08:45:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6236ffbd.676.17588f7729d.Webtop.217@btinternet.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] Use of abbreviations X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 19:45:40 -0000 FYI, the RFC Editor maintains a list of abbreviations. A few of them are = marked as "well known" and can be used in RFCs (and by implication in dra= fts) without expansion. Otherwise, the policy is that abbreviations shoul= d be expanded when first used or in a Terminology section. The list is at https://www.rfc-editor.org/materials/abbrev.expansion.txt TA and OTP are both listed, but without an asterisk, so they should be ex= panded in drafts. However, it's a big ask for people to expand them in em= ails, IMHO. Regards Brian Carpenter On 03-Nov-20 01:38, William_J_G Overington wrote: > Hello Henk >=20 >=20 > Thank you. >=20 >=20 > Best regards, >=20 >=20 > William >=20 >=20 >=20 >=20 >=20 > ------ Original Message ------ > From: "Henk Birkholz" > To: "William_J_G Overington" ; Iotops@ietf.org > Sent: Monday, 2020 Nov 2 At 10:45 > Subject: Re: [Iotops] Use of abbreviations >=20 > Hello William, >=20 >=20 >=20 > thank you for chiming in and speaking out. Sometimes conversations = migrate to a place - hitting the road running - and that can make it more= difficult to join such conversations. >=20 >=20 >=20 > TA typically refers to a Trust Anchor in this context. That word is= given a well-scoped meaning in RFC4949. >=20 >=20 >=20 >=20 >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 >=20 >=20 > Henk >=20 >=20 >=20 > On 02.11.20 09:03, William_J_G Overington wrote: >=20 > Could it be the custom and practice of this mailing list that up= on first use of an abbreviation in a post that the meaning is stated in f= ull please? >=20 >=20 >=20 > Recently I had to look up OTP, I think I found the correct meaning = but I am not congruently sure. >=20 >=20 >=20 > I am still trying to find out what TA means. >=20 >=20 >=20 > When, in another venue, I included mention of a >=20 >=20 >=20 > PDF (Portable Document Format) document >=20 >=20 >=20 > I was informed that readers would know what PDF meant. >=20 >=20 >=20 > So it is a balance. My training was to always explain an acronym th= e first time one uses it, because some readers might not know the meaning= of the acronym. >=20 >=20 >=20 > So, I am retired, at home, just trying to take an interest and part= icipate, I am not "at" an organization and I am "not representing an orga= nization", but hopefully that is fine with the people who are "at" or are= "representing an organization". >=20 >=20 >=20 > William Overington >=20 >=20 >=20 > Monday 2 November 2020 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Iotops mailing list >=20 > Iotops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/iotops >=20 >=20 From nobody Mon Nov 2 15:39:43 2020 Return-Path: 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 258123A12EB; Mon, 2 Nov 2020 15:39:33 -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 WFk9qcMQTwBh; Mon, 2 Nov 2020 15:39:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0743A14D9; Mon, 2 Nov 2020 15:38:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 208C6389A3; Mon, 2 Nov 2020 18:45:15 -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 iId0BP4_ly2X; Mon, 2 Nov 2020 18:45:14 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 36655389A2; Mon, 2 Nov 2020 18:45:14 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A876D1F9; Mon, 2 Nov 2020 18:38:11 -0500 (EST) From: Michael Richardson To: opsawg@ietf.org, Qin Wu , mud@ietf.org Reply-To: mud@ietf.org CC: iotops@ietf.org In-Reply-To: References: 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 Archived-At: Subject: Re: [Iotops] Review comments on draft-richardson-opsawg-mud-acceptable-urls-02 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:39:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-richardson-opsawg-mud-acceptable-urls-03.txt has been successfully submitted by Michael Richardson and posted to the IETF repository. Name: draft-richardson-opsawg-mud-acceptable-urls Revision: 03 Title: Authorized update to MUD URLs Document date: 2020-11-02 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-richardson-opsawg-mud= -acceptable-urls-03.txt Status: https://datatracker.ietf.org/doc/draft-richardson-opsawg-mu= d-acceptable-urls/ Html: https://www.ietf.org/archive/id/draft-richardson-opsawg-mud= -acceptable-urls-03.html Htmlized: https://tools.ietf.org/html/draft-richardson-opsawg-mud-acc= eptable-urls-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-opsawg= -mud-acceptable-urls-03 Based upon unicast comments I received, I have posted a -03 version that ha= s the following changes: > Suggest to add a paragraph to summarize MUD URL updating and MULD file > updating are two options, also explain why MUD URL or files need to be > updated? How about? # Updating MUD URLs vs Updating MUD files +There are two ways in which a manufacturer can change what the is processe= d by the MUD controller: they can change what is in the MUD file (update-in= -place), and or they change which file is processed by the MUD controller b= y changing the URL (updated-url). + > 2. Section 2.1 > How does the end device know the capabilities need to be added or > removed? Is there signaling exchange between end device and firmware > server? If yes, please add reference or clarification text. No, the end device has no knowledge in the device of its capabilities. This is knowledge in the device. The knowledge resides in the manufacturer who creates the MUD file by human= action. > If the device detected the firmware update, does it use the same MUD > URL to retrieve the MUD file? When? The MUD controller (which is not the device, but some role in the network orchestration), is the thing that retrieves the MUD file. Whether or not it uses the same MUD URL or not, is the topic of this sectio= n. > 3. Section 2.1.3 > I see section 2.1.3 are special example of adding capabilities and > removing capabilities? Consolidated into section 2.1.1, 2.1.2? I split out section 2.1.3 so that it could be referred to. In this case, it is unclear if it is adding or removing capabilities. It seems a special, and interesting case. > Is there any software or firmware update in the firewall device or > middlebox when TLS profile is retrieved? This is definitely an issue. There could be, and there has much discussion during the adoption process for I-D.reddy-opsawg-mud-tls about this. Not in scope for this document. > 4. Section 3 said: > " > It should be noted that [RFC8520] > has not established a trust model for MUD controllers to determine wh= ether a signature from a specific > entity is legitimate as a signature for a particular device. > " > Don't understand this sentence, can you give an example to explain > this? I've rewritten like this: =2DIt should be noted that {{RFC8520}} has not established a trust model fo= r MUD controllers to =2Ddetermine whether a signature from a specific entity is legitimate as a =2Dsignature for a particular device. {{RFC8520}} leaves this to the indus= try to work out through supply chain arrangements or other heuristics. +While {{RFC8520}} has established a mechanism for signing of MUD files, th= e document does not define a way for a MUD controller to determine who shou= ld sign the MUD file for a particular device. + +{{RFC8520}} leaves this for a local policy. +There are any number of processes that could be used, but they require coo= rdination of many players. +It is expected that each industrial vertical will work out supply chain ar= rangements or other heuristics. I think that a lot could be said, but I don't want to go down a rathole her= e. Maybe I should? > 5. Section 7 > Is MUD File updating more related to RFC8520 while MUD URL update is > something proposed by this document? > What's your recommendation to the implementers or developer when they > face the choice of MUD URL updating or MUD file updating? Assuming that this document is adopted and MUD controllers implement it, th= en I would set a new MUD URL whenever there was a firmware update that created any change to the behaviour. I would reserve MUD file changes (which also involves signature updates) to fixing bugs in the MUD file only. I have updated: ## Updating files vs Updating MUD URLs + +Device developers need to consider whether to make a change by updating a = MUD file, or updating the MUD URL. + +MUD URLs can only be updated by shipping a new firmware. +It is reasonable to update the MUD URL whenever a new firmware release cau= ses new connectivity to be required. +The updated mechanism defined in this document makes this a secure operati= on, and there is no practical limitation on the number of files that a web = server can hold. + +In place updates to a MUD file should be restricted to cases where it turn= s out that the description was inaccurate: a missing connection, an inadver= tent one authorized, or just incorrect information. + +Developers should be aware that many enterprise web sites use outsourced c= ontent distribution networks, and MUD controllers are likely to cache files= for some time. +Changes to MUD files will take some time to propogate through the various = caches. +An updated MUD URL will however, not experience any cache issues, but can = not be deployed with a firmware update. + + =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+gmGMACgkQgItw+93Q 3WV0jQgAi4V6lsBQBLmzD5K/UQh6K90pzvP/ANp9/eLXSm3uvH+LnzFiIEnsUkFm gEWKF+yJb/QxsgLKl8PYyhHvpzl4CMIXqMMVVbRNEBuIxTRRVuunfv8REjUyyV2E RKIqglxZ1XQJceCxd8hm1EwZMugxD6Uxi+k6vuPSkBkHqG4iWwzTkVB0Ab/1xmMc IOniOhm9jeUMq4cHyhqzOD8QhnQv0haw6imPo82mDtjKCn3so9JFHeAGjvSuxxzS 63fuIHMnQYzhe9eiHQfm8sRuwActQ/1yk5qFHnaVkSL+scJ49kBJ9qmMskTyoT88 M56PCUkJa5ivX8tXA2/qHcmxarYvGg== =HeU7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 04:56:03 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: "iotops@ietf.org" CC: Michael Richardson Thread-Topic: [Iotops] can we create protocols that securely transfer ownership? Thread-Index: Adax3ztq9ZIaKul3Q9OMa0o+CJKXng== Date: Tue, 3 Nov 2020 12:55:53 +0000 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 12:56:02 -0000 On 31-Oct-20 06:25, Michael Richardson wrote: >=20 > Andrew G. Malis wrote: > > Yes, in addition to being a good story, the point is who controls t= he > > 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). >=20 > > Or the issues that arise when the manufacturer fails to properly ma= intain > > the firmware, or goes out of business. >=20 > 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 From nobody Tue Nov 3 05:10:29 2020 Return-Path: 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 275213A09F1 for ; Tue, 3 Nov 2020 05:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=krgB9hkG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CpXSY4Wo 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 0lbCOAAk0XL3 for ; Tue, 3 Nov 2020 05:10:26 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676253A09D5 for ; Tue, 3 Nov 2020 05:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1604409026; x=1605618626; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wlVLDw8zSQ7WnhDi5yMbos+i4wwuIth4BGCLGLL++U0=; b=krgB9hkGOALlhjDPsghBIYG9oQLtlku/vq+4wKVQCJm4s++WmIZ8pEMU lkR9XmhlkBLiW0SVyb005HRWeqGUdmEfcUJJv8c3VxOAX7tsUGE4BxU8s iOvALEITV6zK/3aS4CCBMg47h6knDvZSIiT+ebRA8gJhq8o3PHA0OnGgY U=; X-IPAS-Result: =?us-ascii?q?A0AFJQD1VaFf/4cNJK1YChwBAQE8AQEEBAEBAgEBBwEBF?= =?us-ascii?q?YFRgTwCElEHcFkvLgqHfAOmT4JTA1QLAQEBDQEBIwoCBAEBgVWCdQKCCgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBHGFYQELhgsoBgEBKQ8RAT5CJgEEGxEJg?= =?us-ascii?q?wWCSwMuAQMLpGgCgTuIaHSBNIMEAQEFgUdBgxgYghADBoE2AgEBgnCGPYQLG?= =?us-ascii?q?4FBP4ERQ4VqAgMBgS4EGhGDSIIsuCQKgm2JCpIhoWyTTYp4lUwCBAIEBQIOA?= =?us-ascii?q?QEFgWsjKoEtcBWDJFAXAg2BGZB3hRSFRHQ4AgYKAQEDCXyLBgImgQ0BgRABA?= =?us-ascii?q?Q?= IronPort-PHdr: =?us-ascii?q?9a23=3AAd9oox0CbdSUd+B+smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,448,1596499200"; d="scan'208";a="570404613" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Nov 2020 13:10:25 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A3DAP79010614 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Nov 2020 13:10:25 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 3 Nov 2020 07:10:24 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 3 Nov 2020 07:10:24 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 3 Nov 2020 07:10:24 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QobxihEJwH7G0bdrVEoSTUg3cum6vEECx9vN39rrWxOljY/TsHB4PtqD9MTmO8Uo0NyX3v+swJuI2S+So7Ol/ZItrgbdsrylRaGhSCMVinCwsgy6AbPuCD7il1vDg8I5o5knZ7wFQikw4Si9rWvTVodW1oXw3v1ip0/YtWovL7MJpZlMA2x20C+v975PLLqgKtayg+plSsMLg0FNsDPg9DZEREwntQCHHEWKP6svtueJhzYKxL6bUdKCVp/xdHhzAJK6aYBkNm1muDHkm0CMOYQK3bGrlw+02Osr+vPE5nqhxoMHMHcE9+5OApp+ocQDeY4LmxXmvtbuj4WAhWS4jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xd/LYjsIDmgnb23Kwfi7D35BXxk3RXoRwBpMhiAQBdA=; b=mcR7QRA5dyjGU06Y7BKzL7qddUcTfD3h8/cgl7CzVRHxGtku2LFRbLZswtTm22ZdFXFK4bTm0u26GGG61WQtAK6gLs9WUjLOkKmpOJVgHJsce8iZxrlVY2XcEfWfhnQv/s71rS5eXRPxM2A4xAHjiQbF9cE0SZ0SHZ8QeydqJGCynsIesQ5xaJoxuP3Z7F0BWnhdNpCD+K60HazblMYxSheN6TvIC9oXRbURn6cw/PCDQluGnMXaaLKj7WQIelh/QSgU+4bfnVUslosX4bLuKmkHh3F2ysVNjOuf3CpFQRmQUZL8ZcTE1AXXpZrr1nB5xhs1SsDylhqv3ik/fAnnCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xd/LYjsIDmgnb23Kwfi7D35BXxk3RXoRwBpMhiAQBdA=; b=CpXSY4WoXgbIm1X0HU+66f+pQPtIyJrN9rvMa9ymcBdEAs89Y1sJnRdlYnrY5aNcO+5mxV69jRE22N2HstgDtQayhTjT585N7wstyCxT8C3AtcHM3bGy8iOmqb3xCEjD07nn12FHh309KlmLa5Jjp5DL7JYKYYaWWzX608GRrfA= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3473.namprd11.prod.outlook.com (2603:10b6:208:6e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Tue, 3 Nov 2020 13:10:23 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3499.030; Tue, 3 Nov 2020 13:10:23 +0000 From: "Rob Wilton (rwilton)" To: "iotops@ietf.org" Thread-Topic: IOTOPS Draft Charter Thread-Index: Adax30q2qgoRJah6TfKWMxRovMp5tA== Date: Tue, 3 Nov 2020 13:10:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c18ef0b4-c566-43c7-a21f-08d87ff9d320 x-ms-traffictypediagnostic: BL0PR11MB3473: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xvzMQOYb+PWeggYLhcVgO3VScz9fqo4KZAgLD1wRghOU3FVVBURLTJnBvtWSfDG+vhSjVnZ72HH1FOOZ36iNaPMfq12JFe3jx2ef8ztIKL0F1KnA974Q+8avjdsqlQXKifaYDo2k0XtA4Ou/ojAGP9aGH68FwLKTXQVJ3fSvCe8yEbWCWscTdDDiT6KU+YcSYd71DNaMFatiASwVv/ClMIKvDW3nQBlgqxpfQP/3t8/DgMDE+j9C/5g+HlqZf/CXjJau3/lj6Zkc0M0oMXkQeshvBnp04uUL1tQ5gAe3UycAYHrd/nZDLVImXuSrQVzr/QepNFFSvporIvf0CsqK1x/Ykq2j7Ed2z1r2CCf75R+aLn48MqU1UXGFOjPtC4xSWVEIupkE4Sfe7Wz/98fn3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(366004)(39860400002)(376002)(478600001)(966005)(7116003)(3480700007)(5660300002)(71200400001)(66556008)(66946007)(52536014)(76116006)(64756008)(66446008)(66476007)(316002)(8936002)(9686003)(2906002)(26005)(8676002)(55016002)(33656002)(7696005)(6916009)(66574015)(86362001)(6506007)(186003)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Tob4KGxZ+6svgWP8niecePnxuLZmrZiwdanMLj2X5qNyqO19LocRCHbVxz3q4p1KjSqcxGSA9DiN1Vkxzs7hDqE4hJUwghaHH7okyRIP2+fWI5kuc2eKaJ0f2nMps0WFx/xBvYJVOkhf8ugWXEeweSQllvbP5juswgscrtgTyy7QsHLVVMWXMGmAOQA07anorXg8E2BXS2gHNYJBC8RNeEXAvx+dhE7lw/W1lYFUQzPKTt3aGfIZnea+ozrvB8u6WYsoPdgDo83IFErmi66gHGPamg/+3CNAhpkdfHjEkucUPOUJXwslklkPR6vy7vyMMQwZWkeBqcdeN3ksnhj0C608OjRfyq9hbyTvTn5CmCL8wZk9aufeebuxEZHByUR5lVhc/kzMJAcaJVBKSBlOQ7xlFwn5vy6nBLEKEIO3391je0kyx+6MDX36FbuACy9BCKKr62MUbM8nZiS5ACycmZmaCHWz/ZUBfdpOTcQeVFpdqy6YLu8j5F45jC9RY4gj7TS70w9r+KdKkzlp0E90E7wqWLnZJXjoy0HdHnq2YvqLQOV18XEPqL7S5G8BAcSCojMeXHkXdytCdtvauoNggOOOMZb9V79MOxpyb3Zl7rnbMxRw7ehraGOA1NUXMGb1EYnUFgP/zHlZjOsMyL1uQA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c18ef0b4-c566-43c7-a21f-08d87ff9d320 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 13:10:23.7081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XlSpXDSzvFmHvs5jEOvpugkA1ObihaAUHTw3HWU2rws+EGTRNiFIVYhA1TJlBpcBqfZaCW1U4ymXPSChEYyF1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3473 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 13:10:28 -0000 Hi, An updated draft charter for IOTOPS (also inline) has been posted to https:= //datatracker.ietf.org/doc/charter-ietf-iotops/ This charter has received a couple of rounds of informal review from other = IESG members. Warren and I believe that it is close to the state where we = could ask the IESG to ballot on the draft version before it goes out for pu= blic review. Hence, I think that this would be an appropriate time for discussion of the= proposed charter on the @iotops alias. --- The IOTOPS Working Group is for the discussion of operational issues related to Internet of Things (IoT) devices, in particular related to devic= e onboarding and lifecycle management. IoT has a rather nebulous definition with different meanings for different people. For the purposes of this WG, its focus is on devices that are: - networked - either to the Internet or isolated domain(s), - have a very limited end user interface or no end-user interface at all, - are deployed in sufficiently large numbers that they cannot easily be managed or maintained manually. The IETF is or has worked on a number of technologies related to IoT. These include work done in ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT= , and 6TISCH. IOTOPS is intended to be a discussion venue where people can discuss how the various technologies developed in these WGs fit together, w= hat gaps remain, what has been learnt from deploying these, etc. IOTOPS will solicit input on IoT-device-related operational issues and practices, and existing and proposed technologies related to the deployment= , operational management, and lifecycle management of IoT devices. IOTOPS provides a venue for IoT experts and other interested parties to engage in discussions of IoT requirements of networking standards, as well as proposa= ls for new uses of IP technology in IoT specific scenarios. Revision, updates, and extensions related to existing WGs will be done in t= hose WGs. Where new protocols may be needed, IOTOPS will help identify candidat= e venues within IETF for their development. In this context, IOTOPS will oper= ate with a "dispatch" model as described in RFC 7957. IOTOPS WG charter is restricted to: 1) Taking input and discussing issues related to the operational management= of IoT devices. This includes (but is not limited to): - factory provisioning of devices - onboarding of devices - access control of devices to network resources - administrative control of devices - software/firmware upgrades - isolation/quarantine of devices - remediation of broken devices - end of life management of devices 2) Discussing issues related to IoT operational security. 3) Publish operational practice and document requirements. --- Regards, Rob From nobody Tue Nov 3 05:32:41 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: "iotops@ietf.org" Thread-Topic: Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?) Thread-Index: Adax5R9hLGFGrosVQL6qCfn2q/r3rg== Date: Tue, 3 Nov 2020 13:32:29 +0000 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 13:32:39 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADB1F8C6dggeml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 > 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 specif= ic. > > 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 iss= ue, > 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 wh= at 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 lifetim= e, 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 havi= ng 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 prolifer= ate 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 (Intern= et) 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 vulne= rable. 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 v= oucher 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 --_000_B8F9A780D330094D99AF023C5877DABAADB1F8C6dggeml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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> wrote:

> >     > Yes, in addition to being= a good story, the point is who controls the

> >     > firmware in our things, a= nd how bad it can get not only when the

> >     > manufacturer enforces DRM= , but the gov't enables the behavior

> >     > (criminalizing jailbreaki= ng).

> >

> >     > 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 c= an/should do?

> > I have some very specific ideas which I think are mana= geable and specific.

>

> Both BRSKI and SUIT have minor references to the latter pro= blem, and I

> think that when considering tiny cheap devices it isn't a t= heoretical issue,

> but one that's highly likely. There is also (as for incande= scent light

> bulbs) a strong incentive for manufacturers to sell devices= that are

> designed to break after a while. An expiring certificate wo= uld be a great

> way to break devices remotely, for example.

 

Indeed, before even thinking about transferring ownership i woul= d 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 serv= ice" for it.

Of course, the lifetime-service did not include "maintainin= g 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 al= so proliferate

the notion that certificates have to be renewed periodically wit= h 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 th= ese vendor

abuse of principally sound technical guidance.=

 

As much as i like to explore short lived certificates more in en= vironments

where i can set up the right environment to support that, we sho= uld IMHO

also think about the simplicity of lifetime-long-certificates. W= hich we

currently do not have in web PKI.

 

The fact alone that we do only have in browsers one single TA sp= ace (Internet)

seems to be the worst offender, proliferated by the fact that th= at is the

only domain that most big contributors in the IETF are intereste= d 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 life= time-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 lif= elong

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 tr= ansfer

of ownership again by overwriting the current cert with one of t= he

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 overwritt= en by cert of the new owner.

The current Cert can be embedded in the Cert of new owner, see d= elegation voucher

https://tools.ietf.org/html/draft-richardson-anima-vou= cher-delegation-02

when the device is in resale, wrong?

 

JUst a line of thoughts.

 

Cheers

    Toerless

 

--_000_B8F9A780D330094D99AF023C5877DABAADB1F8C6dggeml511mbschi_-- From nobody Tue Nov 3 05:53:36 2020 Return-Path: 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 3C7B93A0AC1 for ; Tue, 3 Nov 2020 05:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 loNQFGHKJMLL for ; Tue, 3 Nov 2020 05:53:32 -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 553C03A00C9 for ; Tue, 3 Nov 2020 05:53:32 -0800 (PST) Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D3B7AFEB9D0211E942E4 for ; Tue, 3 Nov 2020 13:53:30 +0000 (GMT) Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) 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:53:30 +0000 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml712-chm.china.huawei.com (10.201.108.63) 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:53:30 +0000 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.33]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 21:53:26 +0800 From: Qin Wu To: "Rob Wilton (rwilton)" , "iotops@ietf.org" Thread-Topic: IOTOPS Draft Charter Thread-Index: Adax5sJDqtFl3VHrQtux5YlG1X1z5w== Date: Tue, 3 Nov 2020 13:53:25 +0000 Message-ID: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 13:53:34 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IElvdG9wcyBbbWFpbHRvOmlvdG9wcy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFJvYiBXaWx0b24gKHJ3aWx0b24pDQq3osvNyrG85DogMjAyMMTqMTHU wjPI1SAyMToxMA0KytW8/sjLOiBpb3RvcHNAaWV0Zi5vcmcNCtb3zOI6IFtJb3RvcHNdIElPVE9Q UyBEcmFmdCBDaGFydGVyDQoNCkhpLA0KDQpBbiB1cGRhdGVkIGRyYWZ0IGNoYXJ0ZXIgZm9yIElP VE9QUyAoYWxzbyBpbmxpbmUpIGhhcyBiZWVuIHBvc3RlZCB0byBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtaW90b3BzLw0KDQpUaGlzIGNoYXJ0ZXIgaGFzIHJl Y2VpdmVkIGEgY291cGxlIG9mIHJvdW5kcyBvZiBpbmZvcm1hbCByZXZpZXcgZnJvbSBvdGhlciBJ RVNHIG1lbWJlcnMuICBXYXJyZW4gYW5kIEkgYmVsaWV2ZSB0aGF0IGl0IGlzIGNsb3NlIHRvIHRo ZSBzdGF0ZSB3aGVyZSB3ZSBjb3VsZCBhc2sgdGhlIElFU0cgdG8gYmFsbG90IG9uIHRoZSBkcmFm dCB2ZXJzaW9uIGJlZm9yZSBpdCBnb2VzIG91dCBmb3IgcHVibGljIHJldmlldy4NCg0KSGVuY2Us IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIGFuIGFwcHJvcHJpYXRlIHRpbWUgZm9yIGRpc2N1 c3Npb24gb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgb24gdGhlIEBpb3RvcHMgYWxpYXMuDQoNCi0t LQ0KDQpUaGUgSU9UT1BTIFdvcmtpbmcgR3JvdXAgaXMgZm9yIHRoZSBkaXNjdXNzaW9uIG9mIG9w ZXJhdGlvbmFsIGlzc3VlcyByZWxhdGVkIHRvIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKSBkZXZp Y2VzLCBpbiBwYXJ0aWN1bGFyIHJlbGF0ZWQgdG8gZGV2aWNlIG9uYm9hcmRpbmcgYW5kIGxpZmVj eWNsZSBtYW5hZ2VtZW50Lg0KDQpJb1QgaGFzIGEgcmF0aGVyIG5lYnVsb3VzIGRlZmluaXRpb24g d2l0aCBkaWZmZXJlbnQgbWVhbmluZ3MgZm9yIGRpZmZlcmVudCBwZW9wbGUuDQoNCkZvciB0aGUg cHVycG9zZXMgb2YgdGhpcyBXRywgaXRzIGZvY3VzIGlzIG9uIGRldmljZXMgdGhhdCBhcmU6DQog IC0gbmV0d29ya2VkIC0gZWl0aGVyIHRvIHRoZSBJbnRlcm5ldCBvciBpc29sYXRlZCBkb21haW4o cyksDQoNCltRaW5dOiBJdCBpcyBub3QgY2xlYXIgd2hhdCBpc29sYXRlZCBkb21haW5zIG1lYW5z PyBIb21lIG5ldHdvcmssIGVudGVycHJpc2UgbmV0d29yaywgY2FtcHVzIG5ldHdvcmssIENvbnRl bnQgZGVsaXZlcnkgbmV0d29yaywgSW9UIG5ldHdvcmssDQpJIHdvdWxkIHN1Z2dlc3QgdG8gcmVw bGFjZSBpc29sYXRlZCBkb21haW4ocykgd2l0aCBsaW1pdGVkIGRvbWFpbiBkZWZpbmVkIGluIFJG Qzg3OTkuDQoNCiAgLSBoYXZlIGEgdmVyeSBsaW1pdGVkIGVuZCB1c2VyIGludGVyZmFjZSBvciBu byBlbmQtdXNlciBpbnRlcmZhY2UgYXQgYWxsLA0KICAtIGFyZSBkZXBsb3llZCBpbiBzdWZmaWNp ZW50bHkgbGFyZ2UgbnVtYmVycyB0aGF0IHRoZXkgY2Fubm90IGVhc2lseSBiZQ0KICBtYW5hZ2Vk IG9yIG1haW50YWluZWQgbWFudWFsbHkuDQoNClRoZSBJRVRGIGlzIG9yIGhhcyB3b3JrZWQgb24g YSBudW1iZXIgb2YgdGVjaG5vbG9naWVzIHJlbGF0ZWQgdG8gSW9ULiBUaGVzZSBpbmNsdWRlIHdv cmsgZG9uZSBpbiBBTklNQSwgQ0JPUiwgQ09SRSwgRFJJUCwgTEFLRSwgTFBXQU4sIExXSUcsIFJP TEwsIFNVSVQsIGFuZCA2VElTQ0guICBJT1RPUFMgaXMgaW50ZW5kZWQgdG8gYmUgYSBkaXNjdXNz aW9uIHZlbnVlIHdoZXJlIHBlb3BsZSBjYW4gZGlzY3VzcyBob3cgdGhlIHZhcmlvdXMgdGVjaG5v bG9naWVzIGRldmVsb3BlZCBpbiB0aGVzZSBXR3MgZml0IHRvZ2V0aGVyLCB3aGF0IGdhcHMgcmVt YWluLCB3aGF0IGhhcyBiZWVuIGxlYXJudCBmcm9tIGRlcGxveWluZyB0aGVzZSwgZXRjLg0KDQpJ T1RPUFMgd2lsbCBzb2xpY2l0IGlucHV0IG9uIElvVC1kZXZpY2UtcmVsYXRlZCBvcGVyYXRpb25h bCBpc3N1ZXMgYW5kIHByYWN0aWNlcywgYW5kIGV4aXN0aW5nIGFuZCBwcm9wb3NlZCB0ZWNobm9s b2dpZXMgcmVsYXRlZCB0byB0aGUgZGVwbG95bWVudCwgb3BlcmF0aW9uYWwgbWFuYWdlbWVudCwg YW5kIGxpZmVjeWNsZSBtYW5hZ2VtZW50IG9mIElvVCBkZXZpY2VzLiAgSU9UT1BTIHByb3ZpZGVz IGEgdmVudWUgZm9yIElvVCBleHBlcnRzIGFuZCBvdGhlciBpbnRlcmVzdGVkIHBhcnRpZXMgdG8g ZW5nYWdlIGluIGRpc2N1c3Npb25zIG9mIElvVCByZXF1aXJlbWVudHMgb2YgbmV0d29ya2luZyBz dGFuZGFyZHMsIGFzIHdlbGwgYXMgcHJvcG9zYWxzIGZvciBuZXcgdXNlcyBvZiBJUCB0ZWNobm9s b2d5IGluIElvVCBzcGVjaWZpYyBzY2VuYXJpb3MuDQoNClJldmlzaW9uLCB1cGRhdGVzLCBhbmQg ZXh0ZW5zaW9ucyByZWxhdGVkIHRvIGV4aXN0aW5nIFdHcyB3aWxsIGJlIGRvbmUgaW4gdGhvc2Ug V0dzLiAgV2hlcmUgbmV3IHByb3RvY29scyBtYXkgYmUgbmVlZGVkLCBJT1RPUFMgd2lsbCBoZWxw IGlkZW50aWZ5IGNhbmRpZGF0ZSB2ZW51ZXMgd2l0aGluIElFVEYgZm9yIHRoZWlyIGRldmVsb3Bt ZW50LiBJbiB0aGlzIGNvbnRleHQsIElPVE9QUyB3aWxsIG9wZXJhdGUgd2l0aCBhICJkaXNwYXRj aCIgbW9kZWwgYXMgZGVzY3JpYmVkIGluIFJGQyA3OTU3Lg0KDQpJT1RPUFMgV0cgY2hhcnRlciBp cyByZXN0cmljdGVkIHRvOg0KDQoxKSBUYWtpbmcgaW5wdXQgYW5kIGRpc2N1c3NpbmcgaXNzdWVz IHJlbGF0ZWQgdG8gdGhlIG9wZXJhdGlvbmFsIG1hbmFnZW1lbnQgb2YgSW9UIGRldmljZXMuIFRo aXMgaW5jbHVkZXMgKGJ1dCBpcyBub3QgbGltaXRlZCB0byk6DQogIC0gZmFjdG9yeSBwcm92aXNp b25pbmcgb2YgZGV2aWNlcw0KICAtIG9uYm9hcmRpbmcgb2YgZGV2aWNlcw0KICAtIGFjY2VzcyBj b250cm9sIG9mIGRldmljZXMgdG8gbmV0d29yayByZXNvdXJjZXMNCiAgLSBhZG1pbmlzdHJhdGl2 ZSBjb250cm9sIG9mIGRldmljZXMNCiAgLSBzb2Z0d2FyZS9maXJtd2FyZSB1cGdyYWRlcw0KICAt IGlzb2xhdGlvbi9xdWFyYW50aW5lIG9mIGRldmljZXMNCiAgLSByZW1lZGlhdGlvbiBvZiBicm9r ZW4gZGV2aWNlcw0KICAtIGVuZCBvZiBsaWZlIG1hbmFnZW1lbnQgb2YgZGV2aWNlcw0KDQpbUWlu XTogV2h5IGxpbWl0IHRvIHRhbGtpbmcgaW5wdXQgYW5kIGRpc2N1c3NpbmcgaXNzdWVzLCBJIHRo aW5rIElvVE9QUyBjb3VsZCBiZSBhIGJldHRlciBwbGFjZSBpZiB0aGVyZSBpcyBubyBnb29kIGhv bWUgZm9yIHNvbWUgSW9UIG9uIGJvYXJkaW5nIHdvcmssIEkgYW0gbm90IHN1Z2dlc3QgdG8gcHV0 IGFsbCB3b3JrIGluIHRoaXMgV0csDQpCdXQgYXQgbGVhc3Qgc29tZSBuZXR3b3JrIGJhc2VkIHNv bHV0aW9uIHNob3VsZCBiZSBkb2N1bWVudGVkIGhlcmUuDQoNCjIpIERpc2N1c3NpbmcgaXNzdWVz IHJlbGF0ZWQgdG8gSW9UIG9wZXJhdGlvbmFsIHNlY3VyaXR5Lg0KDQpbUWluXTogSG93IGFib3V0 IGFsc28gY292ZXJpbmcgcHJpdmFjeSBpc3N1ZXMgaW4gSW9UIHNjZW5hcmlvcz8NCg0KMykgUHVi bGlzaCBvcGVyYXRpb25hbCBwcmFjdGljZSBhbmQgZG9jdW1lbnQgcmVxdWlyZW1lbnRzLg0KDQot LS0NCg0KUmVnYXJkcywNClJvYg0KDQotLQ0KSW90b3BzIG1haWxpbmcgbGlzdA0KSW90b3BzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdG9wcw0K From nobody Tue Nov 3 11:01:31 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 3 Nov 2020 14:01:25 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 659726A5 for ; Tue, 3 Nov 2020 14:01:25 -0500 (EST) From: Michael Richardson To: "iotops\@ietf.org" In-Reply-To: References: 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:01:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 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 > wrot= e: >> > > Yes, in addition to being a good story, the point is who con= trols 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 prop= erly 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 s= pecific. >> >> Both BRSKI and SUIT have minor references to the latter problem, and= I >> think that when considering tiny cheap devices it isn't a theoretica= l issue, >> but one that's highly likely. There is also (as for incandescent lig= ht >> 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 =3D> tte wrote: tte> Indeed, before even thinking about transferring ownership i would t= o see what tte> IETF security community can do to remove the current problem of eve= n 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 curr= ent 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 Ti= Vo 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 m= aximum 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 ind= ustrial 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 i= n. tte> Nevertheless, to support what we classically did without crypto, na= mely tte> private networks (with private addresses), we should also have a cr= ypto tte> strategy for such private networks. And in most cases, lifetime-lon= g 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 changin= g 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 lifetim= e-long tte> certs would be an actual transfer of ownership from whaever the ven= dor tte> put in as certs to a cert from the current owner and using a lifelo= ng 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" identi= ty. tte> And of course, when you sell the device, you would need to do trans= fer tte> of ownership again by overwriting the current cert with one of the tte> new owner. Qin Wu 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 n= ew 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. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hqQUACgkQgItw+93Q 3WVhyAf/SM4TAaQh9vQfwVi3oe1IRC1hC/crLpvsgm/PlrFsXrSxsfZCCEQZZQB9 aLuOGHc8BgCe6tTJckcIedt0pKvnhMyjaIqBkfRigO/3RVwIK5P3hOqRPHeoumTv Vy+Qv/LplTr/MkruMMxd9PwlclLZOVfjARQJ++nZ4wJLTMqDsEYI9svfsob/H08l ehqqlqsoj2dE8lXBTIx6HqRAzjDnJGqrJ105ij5KeBDrKGuii+R922iB9O/OU5D1 acI/0zVSjQGCwOy+OyEPlGDlVvXwTg+f2vt9SFsEZ361eQQXbRnVlvmLbPY62Hq1 fJrC28kBUa2Br5CsWlKLOfGRKUDgPw== =mIuE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 11:08:12 2020 Return-Path: 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 D98343A0DC6 for ; Tue, 3 Nov 2020 11:08:10 -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=unavailable 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 Wh77BTNp0YcX for ; Tue, 3 Nov 2020 11:08:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A783A0DC1 for ; Tue, 3 Nov 2020 11:08:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BED683897E; Tue, 3 Nov 2020 14:08:07 -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 BQU3F-SNzPvN; Tue, 3 Nov 2020 14:08:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E05038983; Tue, 3 Nov 2020 14:08:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 36A891683; Tue, 3 Nov 2020 12:50:49 -0500 (EST) From: Michael Richardson To: "Rob Wilton \(rwilton\)" cc: "iotops\@ietf.org" In-Reply-To: References: 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 Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:08:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, The only actual work that I see the WG having is: 3) Publish operational practice and document requirements. Given that the IESG has been clear that it isn't particularly interested in requirements documents with protocols, this means that only "operational practice" documents (BCPs) will wind up here. The "discuss" points (1) and (2) are things that the more open IOT-DIRectorate can already do. I don't really see the point of doing this. To me, the point was to deal with the lifecycle issues of IoT. That's one the list in point (1) was about. There are some serious gaps in the process, and if we can't address those gaps without a lot of back and forth, then I don't see how it contributes t= o much. While I think we need a MOPS-like group (as I understand MOPS, which I don't really), we also need a place to actually get the work done. I understand that there has been negotiation within the IESG, but I have no idea what the objections were, since they haven't been public. I don't believe that the IESG has much IoT, let alone IoT-security expertis= e, so I am skeptical about the objections. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hmHgACgkQgItw+93Q 3WXBqAf+JMigDv1TRmLVig0DPlQftWKt4uU+43ssunC3/1tF8GsvJ/hLSUhHpVJS hGbdbaqDbHcUt3NGlOWlSnbV9cQQ1eQQdGZepcCAiC132w9ggeDakwgztPtcegB2 FTZcHy5GpGC+g+JiVnGp2bbnkOf5MEUUZ2S/SIyXSkPp72jDpsgYuq7I22ddbUcv jUefPgun/hISaP/jBJ7Ujl36zJx8AoUXdlX4eLOgT1RmfoeVP6FfMy3N9drIrsv7 dJMAjnn/ruOO1WvD1WsCTnvzo+ktEUxlIylpAw6hZHGJhe8Kj49N0Y2RDaDdAhKu qgcpmfJ/pvQ3xxlhIAJDMMf6WektMA== =RgjR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 11:09:29 2020 Return-Path: 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 6B3023A0100 for ; Tue, 3 Nov 2020 11:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 X01l4cErB4lQ for ; Tue, 3 Nov 2020 11:09:22 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6A13A0061 for ; Tue, 3 Nov 2020 11:09:11 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 24C03548686; Tue, 3 Nov 2020 20:09:06 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1BC75440059; Tue, 3 Nov 2020 20:09:06 +0100 (CET) Date: Tue, 3 Nov 2020 20:09:06 +0100 From: Toerless Eckert To: Qin Wu Cc: "iotops@ietf.org" , anima@ietf.rg Message-ID: <20201103190906.GD48111@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:09:24 -0000 Thanks, Qin Cross-posting to anima, because i think these discussions apply to any type of (physical) device level certificate wrt. ownership: Most IDevID in TPMs can not be renewed, so they either have infinite lifetime, or the device is preordained trash when the certificate expires. The security problem you are pointing to is called key exhaustion, aka: it does not come from the lifetime, but from how often you use it. One simple way to solve this is not to use such infinite lifetime certs often. This is true for IDevIDs unless you start to do bad protocols that use them often. One simple way IMHO to solve this problem is to make the infinite lifetime certs a local CA and use it to periodically generate new local cert(s) that you use actively. Increases amount of data for cert-chain signaling required though. Wrt. overwriting existing certs: i was just giving an example. Agree that there are various options. Cheers Toerless On Tue, Nov 03, 2020 at 01:32:29PM +0000, Qin Wu wrote: > [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. > > 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 > 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 > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Tue Nov 3 11:10:17 2020 Return-Path: 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 B33643A0100; Tue, 3 Nov 2020 11:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 IM98cew_0QSv; Tue, 3 Nov 2020 11:10:11 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2447E3A0061; Tue, 3 Nov 2020 11:10:10 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C3D69548660; Tue, 3 Nov 2020 20:10:05 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C152D440059; Tue, 3 Nov 2020 20:10:05 +0100 (CET) Date: Tue, 3 Nov 2020 20:10:05 +0100 From: Toerless Eckert To: Qin Wu Cc: "iotops@ietf.org" , anima@ietf.org Message-ID: <20201103191005.GA1329@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:10:13 -0000 Thanks, Qin Cross-posting to anima, because i think these discussions apply to any type of (physical) device level certificate wrt. ownership: Most IDevID in TPMs can not be renewed, so they either have infinite lifetime, or the device is preordained trash when the certificate expires. The security problem you are pointing to is called key exhaustion, aka: it does not come from the lifetime, but from how often you use it. One simple way to solve this is not to use such infinite lifetime certs often. This is true for IDevIDs unless you start to do bad protocols that use them often. One simple way IMHO to solve this problem is to make the infinite lifetime certs a local CA and use it to periodically generate new local cert(s) that you use actively. Increases amount of data for cert-chain signaling required though. Wrt. overwriting existing certs: i was just giving an example. Agree that there are various options. Cheers Toerless On Tue, Nov 03, 2020 at 01:32:29PM +0000, Qin Wu wrote: > [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. > > 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 > 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 > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops From nobody Tue Nov 3 11:17:52 2020 Return-Path: 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 56ED53A10EC for ; Tue, 3 Nov 2020 11:17:51 -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 hoopSU4lFZRR for ; Tue, 3 Nov 2020 11:17:48 -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 D19CA3A0E81 for ; Tue, 3 Nov 2020 11:17:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 15FB138983 for ; Tue, 3 Nov 2020 14:17:48 -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 5xuVdhfvGsTz for ; Tue, 3 Nov 2020 14:17:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 01CD338982 for ; Tue, 3 Nov 2020 14:17:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA1D16A5 for ; Tue, 3 Nov 2020 14:17:46 -0500 (EST) From: Michael Richardson To: "iotops\@ietf.org" In-Reply-To: <20201103191005.GA1329@faui48f.informatik.uni-erlangen.de> References: <20201103191005.GA1329@faui48f.informatik.uni-erlangen.de> 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 Archived-At: Subject: Re: [Iotops] [Anima] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:17:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > One simple way IMHO to solve this problem is to make the infinite lif= etime > certs a local CA and use it to periodically generate new local cert(s= ) that > you use actively. Increases amount of data for cert-chain signaling r= equired though. There is another (new) way which doesn't use the term "CA", which risks visits from lawyers: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ Delegated Credentials for TLS draft-ietf-tls-subcerts-09 Abstract The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. Also: STIR Certificate Delegation draft-ietf-stir-cert-delegation-03 Abstract The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hrNoACgkQgItw+93Q 3WUA1wgAi5sVk0e/3XaHHEcymg/CuA6sSN+rb3MSjJAg1Qw7l6emvgqyGzkGRruD joaAjvK8Ya/rrr4rP5BXo8j0ncD7XoHIluEL28JIWUOi5rkNBUYO72xFpwlmlpmL RdaEzKhPeW96JzPMN+nt0bCkgAAyyoPqtfWVJw21453c3q4y3uqOp4Pk7KbBsnEw JjnL2hL/Nm4GDpg2Bk2v2crTPzqvwZ4Ttnu0ctetBFh3FUmcAObdqJSBwiEFseMG h1DCw35xCNh8zqJOYF/nk54BJefRvOIatrbBlsZjPhBeunLcXK1Y/z2C04T8dhL6 4IRahyuOcxzWtIz1op4KhmgBcLjzzA== =SlHR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 11:33:22 2020 Return-Path: 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 CF59F3A10FE; Tue, 3 Nov 2020 11:33:11 -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 Nv8jGMNBEjsh; Tue, 3 Nov 2020 11:33:10 -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 0227A3A10FD; Tue, 3 Nov 2020 11:33:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDB0938983; Tue, 3 Nov 2020 14:33:08 -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 QLdOaT7JMyjY; Tue, 3 Nov 2020 14:33:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F19138982; Tue, 3 Nov 2020 14:33:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 164E9134A; Tue, 3 Nov 2020 12:05:35 -0500 (EST) From: Michael Richardson To: anima@ietf.org, netconf@ietf.org cc: iotops@ietf.org X-Attribution: mcr 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 Archived-At: Subject: [Iotops] what to call different RFC8366 format artifacts X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:33:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, RF8366 specifies a YANG module for a voucher, and the format as serialized to JSON, and signed by CMS. In section 5.4, it is written: 5.4. CMS Format Voucher Artifact The IETF evolution of PKCS#7 is CMS [RFC5652]. A **CMS-signed voucher*= *, In section 8.3, it is written: Encoding considerations: *CMS-signed JSON* vouchers are ASN.1/DER encoded. So it became natural for me to write "CMS-signed-JSON". In development of RFC8366, we argued for using JOSE rather than CMS, but there were, at the time (2016) lack of familiarity with JOSE, and concerns about having FIPS-140 validation of that code. In draft-ietf-anima-constrained-voucher, we introduce two new things: 1) signing with COSE 2) encoding with CBOR. A number of people have written, rather than "CMS-signed-JSON", instead, "JSON in CMS". I wondered at the BRSKI design team call last Thursday if perhaps that order of words translates better into Dutch or German, or ??? So to bikeshed the whole thing, please comment on preference in naming: 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. I note that for some of these "signed" is redundant. We do not have COSE-signed-JSON, or JWS-signed-CBOR. Which feels more natural to you? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hjd4ACgkQgItw+93Q 3WVvXwf/cqY6msnbIXpyZ0TXSM1tMCdtZfo+rS2avcu9bIiX1hCiSgdUZMf2LOiq 1NnYksEU20j7TweEAwofBIxu0xxiARJSTCrxQzNBsobEJo7j6eiYgcokJUBvz6Cp Tfs24ZkTS+EFR4Rkq21RweLcNgWWp/kFS3E7k/Bw1uwkhtpu7O2P6xDLxCg3U/lc dQO2znTV/N+KJbE8it+R9+Wy2YY7hy0QFgacmmmHEP/fBf7dQXCEa5brW9uWpMdV zgl9iIWsmFTiyd0dg0DBShMvWT0Q+Umyka50OMqSnKSR2f4wbzC45o77FaFOgf6V HyI3riIx0XblJuoc9fayxMcc9+a0IQ== =pxj+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 12:24:24 2020 Return-Path: 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 A564C3A1135; Tue, 3 Nov 2020 12:24:22 -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 wtsTLUmfx8k4; Tue, 3 Nov 2020 12:24:21 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D413A113B; Tue, 3 Nov 2020 12:23:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 749C4854; Tue, 3 Nov 2020 21:23:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ObAntJ8Bx1Sk; Tue, 3 Nov 2020 21:23:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 3 Nov 2020 21:23:57 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id E831A20156; Tue, 3 Nov 2020 21:23:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id Ds3g93OWxgX9; Tue, 3 Nov 2020 21:23:56 +0100 (CET) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 569BE20154; Tue, 3 Nov 2020 21:23:55 +0100 (CET) Date: Tue, 3 Nov 2020 21:23:55 +0100 From: Juergen Schoenwaelder To: Michael Richardson Cc: anima@ietf.org, netconf@ietf.org, iotops@ietf.org Message-ID: <20201103202355.c4nnbsb5eiu6ga3y@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Richardson , anima@ietf.org, netconf@ietf.org, iotops@ietf.org References: <19352.1604423135@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19352.1604423135@localhost> Archived-At: Subject: Re: [Iotops] [netconf] what to call different RFC8366 format artifacts X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 20:24:23 -0000 On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote: > > So to bikeshed the whole thing, please comment on preference in naming: > > 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. > 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. > 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. > 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. > > I note that for some of these "signed" is redundant. > We do not have COSE-signed-JSON, or JWS-signed-CBOR. > > Which feels more natural to you? > For me, all the $foo-signed-$bar expansions make sense and they stress the signature aspect: CMS-signed-JSON = Cryptographic Message Syntax signed JavaScript Object Notation CMS-signed-CBOR = Cryptographic Message Syntax signed Concise Binary Object Representation COSE-signed-CBOR = CBOR Object Signing and Encryption signed Concise Binary Object Representation JWS-signed-JSON = JSON Web Signature signed JavaScript Object Notation The $foo-in-$bar alternative somehow stresses containment but I assume the primary reason for using CMS / COSE / JWS is for signatures, not for containment. /js (German, in case that matters.) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Nov 3 12:51:35 2020 Return-Path: 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 3013C3A1210 for ; Tue, 3 Nov 2020 12:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vsbh3EeEfQSl for ; Tue, 3 Nov 2020 12:51:30 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12AC3A1C18 for ; Tue, 3 Nov 2020 12:48:29 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C6F0254865F; Tue, 3 Nov 2020 21:48:23 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C1D89440059; Tue, 3 Nov 2020 21:48:23 +0100 (CET) Date: Tue, 3 Nov 2020 21:48:23 +0100 From: Toerless Eckert To: Michael Richardson Cc: "iotops@ietf.org" Message-ID: <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> References: <15665.1604430085@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15665.1604430085@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 20:51:33 -0000 On Tue, Nov 03, 2020 at 02:01:25PM -0500, Michael Richardson wrote: > 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? I don't know whether or not it was used to connect to the cloud service. I would assume it didn, i should have wiresharked this. It was used for (legal, TiVO permitted ;-) https download of recordings, so the box became logically unusable for the intended purpose (download recordings for watching later on a different device). > 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. IETF also had its own opinion about X.5xx and those standards RFC are now industry standards overriding X.5xx, so why not about this lifecycle managment ? something like iotops would be a possible place to do this for such type of consumer/... devices. But not precluding other IETF WG. > 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. Right. Process / proces-profile BCP. Remember my slides showing Homer Simpson as the registrar ? That level of abstraction process definitions might help (if need be without home ;-) > 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. Yes, different TA realms is a very good design starting points for different network domains that need to be isolated from each other at the end-to-eend layer. Whether is a same browser or new tabs (white=internet, black=internet-"anonymous", red="private-network") is IMHO secondary. I do agree though that a browser for a lot of iot management cases could be a lot smaller than an Internet browser, so it would fit itself easier into embedded devices itself and be a lot more reliable and predictable in its page rendering than all the horrenduously complex options-galore W3C has produced for "The Internet TA realm". > 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? I for once would appreciate if my home gateway would be a TLS proxy that can see the actual payload passed between my home IoT devices and the cloud. Especially to allow ME to PERVASIVELY MONITOR what all those iot devices do to the cloud. Aka: Only this monitoring/filtering TLS proxy would be given TA to both realms on either side. I am quite certain that most if not all of industrial device security policies would expect to have an equivalent level of security policy rquirements. Just the protocols (TLS) would be different for them. Like at least 20 variations of MQTT brokers instead of TLS proxies or the like. I highlighted specific words because i think iot operations in IOT will get nowhere unless it becomes clear that such functions are mandatory for many iot use cases, and i can't wrap my head around why not every contributor already sees them as crucial for their own personal use of networking. The iotops charter for example also does not talk about data management for iot devices. This type of security operations would fall into that type of charter point. > We don't have Cu (CoAP support)in Firefox anymore, because one can't write > new schemes as extensions due to security architecture changes. Ok, i don't get that. > 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. Somebody more tortured by the variety of iot relevant device to cloud protocols should give an overview of all the stuff that will stay relevant and would be within scope of IETF. I would suspect that https/coap are reall just a smaller subset of what is relevant, so for a BCP or process document it would initiallybe more important to identify those protocols and see what scheme of evolution for multiple TA realms might equally work across them instead try to figure out a one-off solution for one protocol. Of course, experimentation on any individual protocol is highyl welcome, it just shouldn't be taken as a suggested general principle unless we know it can map to other protocols. > 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). Yepp. And with those huge browser we have today, i would really like to use something like containers to create disjoint running instances with safely isolated-from-each other profiles. Instead of trusting the browsers to keep those profiles apart. Alas, never started to see how difficult it would be to install multiple instances of e.g. chrome via docker. But foremost one would need a way to sufficiently influence look&feel of each instance to be differnt (color scheme of borders or the like). > 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. IN L3VN we developed the notion of RD and RT to express partial overlap of "reachability". I am sure if we want to shoot ourselves security wise into the feet with complex partially overlapping TA realms/imports into context and the like, we can steal a lot from L3VPN ;-)) > 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 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. When we discussed BRSKI and change of ownership in the past years it was always mitigated through the MASA and therefore vendor. I think that is an important option. I would like to see the option of being able to do this without any vendor/MASA involvement of course too. I don't think it would be a problem to define suh a process, but i really would prefer we would define those workflows abstract first so they're not stuck in a specific protocol like BRSKI, but could more esily be proliferated across various protocols faster. aka: for the least difficult to implement "sell-on-ebay" option, you as the outgoing owner could create a bearer token, and send that in email to the ebay buyer and in parallel ship the product. Then the receiving new owner could take ownership. But the vendor should not be able to dis-own the product unless you as the owner explicitly create a bearer-token. --- just as an example. A device could keep track of prior owner LDevID/TA or not ... different issue. Cheers Toerless > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Tue Nov 3 22:22:43 2020 Return-Path: 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 9C2733A096B; Tue, 3 Nov 2020 22:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 mnvU9PFTynUL; Tue, 3 Nov 2020 22:22:31 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41E3A0966; Tue, 3 Nov 2020 22:22:31 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CQxP83FlHz67HRW; Wed, 4 Nov 2020 14:21:16 +0800 (CST) Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 07:22:29 +0100 Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 07:22:29 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 4 Nov 2020 07:22:29 +0100 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; Wed, 4 Nov 2020 14:22:26 +0800 From: Qin Wu To: Juergen Schoenwaelder , "Michael Richardson" CC: "netconf@ietf.org" , "anima@ietf.org" , "iotops@ietf.org" Thread-Topic: [Iotops] [netconf] what to call different RFC8366 format artifacts Thread-Index: AdaycqUnE+dI0q33R0aqGlmGJZ5ZdA== Date: Wed, 4 Nov 2020 06:22:25 +0000 Message-ID: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Iotops] [netconf] what to call different RFC8366 format artifacts X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 06:22:34 -0000 QWdyZWUgd2l0aCBKdWVyZ2VuLCB0aGVzZSBhcnRpZmFjdHMgYXJlIGFsbCBDTVMgc2lnbmVkLWRh dGEgY29udGVudA0KVHlwZSwgc28gQ09TRSBzaWduZWQgQ0JPUiwgSldTIHNpZ25lZCBKU09OIGlz IG1vcmUgbmF0dXJlIHRvIG1lLg0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog SW90b3BzIFttYWlsdG86aW90b3BzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbiBTY2hv ZW53YWVsZGVyDQq3osvNyrG85DogMjAyMMTqMTHUwjTI1SA0OjI0DQrK1bz+yMs6IE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0Ks63LzTogbmV0Y29uZkBpZXRmLm9y ZzsgYW5pbWFAaWV0Zi5vcmc7IGlvdG9wc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtJb3RvcHNdIFtu ZXRjb25mXSB3aGF0IHRvIGNhbGwgZGlmZmVyZW50IFJGQzgzNjYgZm9ybWF0IGFydGlmYWN0cw0K DQpPbiBUdWUsIE5vdiAwMywgMjAyMCBhdCAxMjowNTozNVBNIC0wNTAwLCBNaWNoYWVsIFJpY2hh cmRzb24gd3JvdGU6DQo+IA0KPiBTbyB0byBiaWtlc2hlZCB0aGUgd2hvbGUgdGhpbmcsIHBsZWFz ZSBjb21tZW50IG9uIHByZWZlcmVuY2UgaW4gbmFtaW5nOg0KPiANCj4gMSkgUkZDODM2NjogICAg Q01TLXNpZ25lZC1KU09OICB2cyBKU09OLWluLUNNUy4NCj4gMikgQ1Y6ICAgICAgICAgQ01TLXNp Z25lZC1DQk9SICB2cyBDQk9SLWluLUNNUy4NCj4gMykgQ1Y6ICAgICAgICAgQ09TRS1zaWduZWQt Q0JPUiB2cyBDQk9SLWluLUNPU0UuDQo+IDQpIGZ1dHVyZSBJRDogIEpXUy1zaWduZWQtSlNPTiAg dnMgSlNPTi1pbi1KT1NFLg0KPiANCj4gSSBub3RlIHRoYXQgZm9yIHNvbWUgb2YgdGhlc2UgInNp Z25lZCIgaXMgcmVkdW5kYW50Lg0KPiBXZSBkbyBub3QgaGF2ZSBDT1NFLXNpZ25lZC1KU09OLCBv ciBKV1Mtc2lnbmVkLUNCT1IuDQo+IA0KPiBXaGljaCBmZWVscyBtb3JlIG5hdHVyYWwgdG8geW91 Pw0KPg0KDQpGb3IgbWUsIGFsbCB0aGUgJGZvby1zaWduZWQtJGJhciBleHBhbnNpb25zIG1ha2Ug c2Vuc2UgYW5kIHRoZXkgc3RyZXNzIHRoZSBzaWduYXR1cmUgYXNwZWN0Og0KDQpDTVMtc2lnbmVk LUpTT04gID0gQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCBzaWduZWQNCiAgICAgICAgICAg ICAgICAgICBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiBDTVMtc2lnbmVkLUNCT1IgID0gQ3J5 cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCBzaWduZWQNCiAgICAgICAgICAgICAgICAgICBDb25j aXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gQ09TRS1zaWduZWQtQ0JPUiA9IENCT1Ig T2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gc2lnbmVkDQogICAgICAgICAgICAgICAgICAg Q29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIEpXUy1zaWduZWQtSlNPTiAgPSBK U09OIFdlYiBTaWduYXR1cmUgc2lnbmVkDQogICAgICAgICAgICAgICAgICAgSmF2YVNjcmlwdCBP YmplY3QgTm90YXRpb24NCg0KVGhlICRmb28taW4tJGJhciBhbHRlcm5hdGl2ZSBzb21laG93IHN0 cmVzc2VzIGNvbnRhaW5tZW50IGJ1dCBJIGFzc3VtZSB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHVz aW5nIENNUyAvIENPU0UgLyBKV1MgaXMgZm9yIHNpZ25hdHVyZXMsIG5vdCBmb3IgY29udGFpbm1l bnQuDQoNCi9qcyAoR2VybWFuLCBpbiBjYXNlIHRoYXQgbWF0dGVycy4pDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KLS0NCklvdG9wcyBtYWlsaW5nIGxpc3QNCklv dG9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3Rv cHMNCg== From nobody Wed Nov 4 10:30:17 2020 Return-Path: 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 C6E9A3A1542 for ; Wed, 4 Nov 2020 10:30:14 -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 gOyxf6oMJUGk for ; Wed, 4 Nov 2020 10:30:12 -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 AE7A23A153C for ; Wed, 4 Nov 2020 10:30:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 11CE438A8C; Wed, 4 Nov 2020 13:30:15 -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 R5dnKGJZYDoh; Wed, 4 Nov 2020 13:30:13 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C95438A8A; Wed, 4 Nov 2020 13:30:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 454E026; Wed, 4 Nov 2020 13:30:09 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: "iotops\@ietf.org" In-Reply-To: <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:30:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: >> 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? > I don't know whether or not it was used to connect to the cloud > service. I would assume it didn, i should have wiresharked this. It w= as > used for (legal, TiVO permitted ;-) https download of recordings, so > the box became logically unusable for the intended purpose (download > recordings for watching later on a different device). tte> I am saying the IETF is partially to blame because i think we also tte> proliferate the notion that certificates have to be renewed tte> periodically with maximum usual lifetimes of now i think one year ? tte> (was two years) THIS IS NOT AN IETF POLICY. > Whether is a same browser or new tabs (white=3Dinternet, > black=3Dinternet-"anonymous", red=3D"private-network") is IMHO second= ary. I > do agree though that a browser for a lot of iot management cases could > be a lot smaller than an Internet browser, so it would fit itself > easier into embedded devices itself and be a lot more reliable and > predictable in its page rendering than all the horrenduously complex > options-galore W3C has produced for "The Internet TA realm". I don't see what a use case for a browser in an IoT device. A fridge with a panel? Sure, but it's probably big enough to an RPI or Android equivalent OS inside, so it's not really constrained. > The iotops charter for example also does not talk about data manageme= nt > for iot devices. This type of security operations would fall into that > type of charter point. Our charter says: } This includes (but is not limited to): } - factory provisioning of devices } - onboarding of devices } - access control of devices to network resources } - administrative control of devices } - software/firmware upgrades } - isolation/quarantine of devices } - remediation of broken devices } - end of life management of devices I thought that it included backup/restore of configuration explicitely. The reason that this is important is because is a broken device is replaced, then you want to be able to transfer the configuration from the broken devi= ce to the new device. If the device abruptly (blue smokes gets out, being bricked, etc.) then in order to have the old configuration requires that something back is up regularly. Ideally, configuration backup/restore should be independant of device type. I don't know if YANG/RESTCONF has a generic way to get all things at this point. Perhaps it does. AFAIK, there is nothing like snmpwalk in RESTCONF, but that's effectively what we need. >> We don't have Cu (CoAP support)in Firefox anymore, because one can't >> write new schemes as extensions due to security architecture changes. > Ok, i don't get that. There was a plugin for firefox called "Cu" https://github.com/mkovatsc/Copper It implemented CoAP as a firefox extension. My understanding is that Firefox changed things when they rewrote things in Rust. Specifically, an extension can't register a new scheme (i.e. coaps), = because that opened the possibility that an extension would register and override "= https". Clearly, we need some other modular mechanism where we can get CoAP support= back. Copper was AWESOME. I think that I had an old firefox install just to run it,, but I don't know where I put that. > Somebody more tortured by the variety of iot relevant device to cloud > protocols should give an overview of all the stuff that will stay > relevant and would be within scope of IETF. I would suspect that > https/coap are reall just a smaller subset of what is relevant, so for For industrial/data-acquisition IoT MQTT is where it's at. There is a TLS-profile specification for it in ACE, I think. Critical to using MQTT safely is per-device identity and TLS Client Authentication, with private keys stored in a hardware TPM. >> 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. > When we discussed BRSKI and change of ownership in the past years it > was always mitigated through the MASA and therefore vendor. I think > that is an important option. I would like to see the option of being > able to do this without any vendor/MASA involvement of course too. > I don't think it would be a problem to define suh a process, but i re= ally > would prefer we would define those workflows abstract first so they're > not stuck in a specific protocol like BRSKI, but could more esily be > proliferated across various protocols faster. Well, I'm not sure I understand what you are saying. Perhaps you are saying that the Registrar concept needs to be abstracted and applied to many protocols? EAP-NOOB and DPP are both manufacturer-free onboarding processes. EAP-NOOB has an AAA server, which is morally equivalent to a Registrar, but it does not currently lead to an ownership transfer. DPP is more nebulous, but the RIPE not-a-BCoP [cf: Good Place, "not a girl"] tries to outline how it might be made more easily deployable. https://www.ripe.net/ripe/mail/archives/iot-wg/2020-October/000537.html see section _Router-Led DPP Activity_ to make this work, we really need a standard API into the Home Router. BFF USP/TR-369 has potential, but it's gonna take some running code to make the profile a little more clear. I'm completely uncertain if such a Home Router/Smartphone onboarding API would be in scope or not for IOTOPS. Is it Operational Practice? > aka: for the least difficult to implement "sell-on-ebay" option, you = as > the outgoing owner could create a bearer token, and send that in email > to the ebay buyer and in parallel ship the product. Then the receiving > new owner could take ownership. But the vendor should not be able to > dis-own the product unless you as the owner explicitly create a > bearer-token. --- just as an example. We can implement this interaction with delegated-voucher "today" =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+i8zEACgkQgItw+93Q 3WXghwf+Psma53jHvEIaWspR/pYx02rjabb5eBjQDOfpQ8xi9Z8bfzGGTk9ptnt9 qo1aw1xoBwbYqUvALYAz59LmjEded8n/93/ihNXbZD54fG251/r3CpC2SDat5t+/ fVaCFk3HVHtExkYenvn7Vl5h/4F7QeYrTlR8+yoNDyPbpP3La7aXtczCyBoO78E6 KAHg4lpPDPvv2+3JbyeHaJLwEm4CM6cDsCx0NayR3LEfbR1MiiQKQlL1ec7wqb/I VU+74cJpsdQ7W6FOvLZlvcTSKHZ0CIIPpHA588SaVM/+cme6kYzbYz29USbaiPNL 0guVVUoNkXeJmthCU6CZxZVW796AFg== =13VX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 11:48:16 2020 Return-Path: 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 D53DA3A0978 for ; Wed, 4 Nov 2020 11:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NyuxP_OaNQHs for ; Wed, 4 Nov 2020 11:48:13 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55D23A064A for ; Wed, 4 Nov 2020 11:48:13 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id e7so18143654pfn.12 for ; Wed, 04 Nov 2020 11:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5vV2D//qoyduWkI0ZjmHF7Sm0HAQsA2kDatykYZyrkA=; b=DhnCAGfpp3ryWzoLypaGPXKI7j/jjnJuht5vc8c6o9uP+4j0ohO59Nmdz9egClBknL gJy3jQisKhWlCTvbrsvjipzkFeSIingPKOzeYH3f0gGN7BCBXf/MDCuY7fYrrJ2g/My0 qHXF6IHtdpv8PGeq63Fci0VyTxV2YxBVelWtO6PFe4G1Lo8ttQwIzST0FTHz47Cec/WO CmnoDt2Lewg855UUIYSTuSim59AMCIdWe5pn5a49xIEYhcxSNP6msJ/v/p/31IV9kreo CVME0CTlghB4CYFSk6FSMWxV/Y4wHHezgFGbdfJCsORY1UuRCAz33qMDwvDOofxGSU8Z 7DNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5vV2D//qoyduWkI0ZjmHF7Sm0HAQsA2kDatykYZyrkA=; b=ES62SC0hC0VdfQHCT6sfLmbnUBQFGMr3MGIgscCG7rlUhhvHW1UuPhQ+Isb9jcwSFh /djmIxz3+PeC2h3j2qC7Su0mV6DwZxJQ5X9kl79d2/6yWC7jctVxlYAJx0rZBQQu+wWF GLSpw/fGiLE/Ju516diR7h7U5CRQkyq59X4C99IvM7IOty8GVdE5itP4ScdVWVSSKAog TKSiXYXGEfFRLcv+hAHs3yAGmpQ0JhcOe7b9mJMOFIO7EKOA+tjwRa2v250jnejk6GFY lL0WZ58cbm42o3nAOaLotVoSR9867CNMdbNmAqpsEnUZ98eq8P69qlH1O4l8fkqExU96 KBnw== X-Gm-Message-State: AOAM530gLAhX9l7ptyieXZRGM3+mUDWAx8R5sD2qa2WCbKjEo25PISfS ZqdT5DXZXr+WVYVvQns4/yyun+fz7UhZhQ== X-Google-Smtp-Source: ABdhPJxuIZSJXyl1yILERQy0ONzo0sWxdTgdBoHHtHmU9/rTwhuItcqO312kZqHHnwCs/HtIu5AgJg== X-Received: by 2002:a62:f94d:0:b029:15c:f1a3:cd47 with SMTP id g13-20020a62f94d0000b029015cf1a3cd47mr31321144pfm.81.1604519293041; Wed, 04 Nov 2020 11:48:13 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id d123sm3173268pfa.206.2020.11.04.11.48.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 11:48:11 -0800 (PST) To: Michael Richardson , "Rob Wilton (rwilton)" Cc: "iotops@ietf.org" References: <31244.1604425849@localhost> From: Brian E Carpenter Message-ID: <2263e2f5-0f65-ac43-5d6a-ed5354251da8@gmail.com> Date: Thu, 5 Nov 2020 08:48:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <31244.1604425849@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:48:15 -0000 On 04-Nov-20 06:50, Michael Richardson wrote: > > Hi, > > The only actual work that I see the WG having is: > 3) Publish operational practice and document requirements. On 04-Nov-20 02:53, Qin Wu wrote: > [Qin]: Why limit to talking input and discussing issues, I think IoTOPS could be a better place if there is no good home for some IoT on boarding work, I am not suggest to put all work in this WG, > But at least some network based solution should be documented here. What struck me is that the draft charter does not talk about active coordination between diverse WGs or about the overall architecture that we should be working towards. By simply listing 10 WGs, the charter itself tells us that there is an enormous coordination issue here and a desparate need for a coherent architecture. Perhaps the coordination is the job of the IOT-DIR and the ADs involved, but whose job is the architecture? Who writes the description of how everything fits together? Brian From nobody Thu Nov 5 04:55:45 2020 Return-Path: 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 5597D3A13A6 for ; Thu, 5 Nov 2020 04:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ambotec.org 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 HfTXlUiT2YIg for ; Thu, 5 Nov 2020 04:55:42 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616463A1773 for ; Thu, 5 Nov 2020 04:55:42 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id x7so1653034wrl.3 for ; Thu, 05 Nov 2020 04:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambotec.org; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=IgQ0omUNjnLpSQewIcpAco/UmmKb6UxjtGVyuREtud8=; b=KM64TjTxX9XS9i9aNefyDYpj9G7QyjFinMkacOF6InZ/Lb0xrl/AEgEg7fztC2Plkn I6nFIDRpFkCCFmMjcZIpoaqtsDnoDwR3dyW6em3xvU/8p9b+MOi9om+1so5KmiUkCaWo 18hoUy5o8lmx/pfPm90f7JQ4KJSfJx0LFrsr4yjxQ1tbwZDl/5wcL9s3hbSrL2oyPWPl VbhlfQ1GJWDtLPl8WbuSvHj0dx4uOhHPnY37XcmAjK2dAjyVg8Vo+D9+xHL81TsiP8nc /WRz8EwAGdURlwqkQrOMn5h5hBInBBRPvTDoiLZqdikFKLvgBaiSLE2tF0Y2p6llZq8T Fr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=IgQ0omUNjnLpSQewIcpAco/UmmKb6UxjtGVyuREtud8=; b=Lap42jCjvedBozycDTk4C/jUCtaMMV9JOLKqR6WDJS57YaddZM8vvTfdFT+fwZ9bz2 0bGQmuiFrAcBT+dKpCxb1UVLNOmZJphVCGSAU9Aco/GgmDOlBEV4VJsb9AYei2yBXj3W WhCZs1N40R/LBOPayydZv0T2RcpweU7zNKO6xuGZOyN7PuGf1UPJmRUrRqMZKW7Sqh1J nN2TJC3w6fOa3I6f6nrLCFWI7eyDuGcU3hF8VH/p2wgznsRVFThr0uYkUL706jKFc1LF PG25fXDXtG3db5NNG34afT1MvMt5HatqQadj3VPTXMMv8p71l858aSnbfV3/IDj0eVNB RZHw== X-Gm-Message-State: AOAM531UpHneQlbf4QsYQCuKKLb3OUfHnscw3dinZFPDX8iUQP8Ee1hT GjW7yxRDI+c+ZJATg+YfoK/MdsAROA066mxBhm4= X-Google-Smtp-Source: ABdhPJyLQ/c6tTls0skbQMvNKa47wiBFCoqTnwWvSBrIomdZvw6Y0mBwFDInbtEDbqUhDtdax+bWng== X-Received: by 2002:adf:8296:: with SMTP id 22mr2791900wrc.341.1604580939892; Thu, 05 Nov 2020 04:55:39 -0800 (PST) Received: from [10.6.3.73] ([194.35.233.182]) by smtp.gmail.com with ESMTPSA id n9sm2313564wmd.4.2020.11.05.04.55.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 04:55:39 -0800 (PST) From: "Amyas Phillips, Ambotec" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 5 Nov 2020 12:55:38 +0000 References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> To: "iotops@ietf.org" In-Reply-To: <5254.1604514609@localhost> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 12:55:44 -0000 Hi folks Is there a definition of ownership you are using? If not I=E2=80=99d = like to propose one because I've found ownership to be a not = particularly useful concept in IoT, unless redefined.=20 - Ownership as a fundamental legal concept of capitalist societies means = having the rights to dispose of an asset how you please, including = improving it and deriving benefits from it.=20 - Assets historically were strictly physical.=20 - When patents were invented it started being possible to own an object = without having the right to physically copy it.=20 - When copyright was extended to compiled software it started being = possible to own an embedded device without having the right to copy its = software. - DMCA and EUCD and equivalents further removed the right to even modify = the software. - Most IoT devices are now sold with EULAs, constraining any remaining = legal concept of ownership with contractual terms.=20 - You can even find that a licence to use it is the only thing you get = when you buy a device, legal title remaining with the vendor. I=E2=80=99d like to suggest that we set aside legal title and say = =E2=80=9Cownership=E2=80=9D for the purpose of this discussion means = =E2=80=9Clogical control of a device=E2=80=9D. Transfer of logical = control is an important and delicate event in an IoT device=E2=80=99s = lifecycle so this seems to fit within the aims of the charter, even if = it isn=E2=80=99t mentioned explicitly. I=E2=80=99d like to further suggest that logical control ultimately = means the right to control what software is installed on a device. That = is to say, ownership =3D=3D logical control =3D=3D the right to set and = (if transfer of control is supported) replace the firmware update trust = anchor. That is what ownership means. Every other form of control is = delegated from that and is called something other than =E2=80=9Cownership"= .=20 That=E2=80=99s it.=20 I=E2=80=99ve anticipated and tried to answer some possible objections. = They run on a bit, sorry about that:=20 1. What if an IC has an integrated secure element under logical control = of a third party and it is impossible even for a person with legal title = to seize control of that SE?=20 That=E2=80=99s fine, just acknowledge the SE as a separate domain of = control. Someone has physical title, possibly constrained by license = terms. Someone has logical control of the SE. Someone has logical = control of the =E2=80=98insecure=E2=80=99 computing environment. It = would a similar situation in a device with a main application processor = and separate a wireless module with its own firmware.=20 2. Wouldn=E2=80=99t this mean that any device whose firmware has to be = signed by its OEM is still under the logical control of and =E2=80=9Cowned= =E2=80=9D by that OEM?=20 Yes. 3. But that=E2=80=99s not who I mean when I talk about the owner!=20 I get it, but this just means different and more specific terminology is = required. You might mean the entity trusted by the device to issue = application-layer commands (possibly including commands to set = application-layer trust anchors). 4. What if an OEM retains firmware update rights but no direct = connection, do they still have ultimate logical control?=20 Yes. 5. What if the application can=E2=80=99t be updated?=20 Logical control has been permanently delegated to whoever the device's = application layer trusts. There always was control at the application = layer, just in this case it is =E2=80=9Cultimate=E2=80=9D control. = Assuming the application exposes logical interfaces and authenticates = requests to them there are could be as many logical controllers / = "owners" as there are trust anchors for authenticating them, but if = there is one interface specifically for administering trust anchors then = whoever controls that who is now the ultimate logical controller / = =E2=80=9Cowner=E2=80=9D.=20 It has to be said that what can be controlled in this situation is much = less than what someone with firmware update rights would be able to = control. Also, unless the new owner is able to validate the installed = firmware against a build of the source code there=E2=80=99s no way they = can know just what they are controlling.=20 6. What if the device ships without trust anchors, who owns it then?=20 It is in a first-to-claim state. That assumes that once =E2=80=9Cclaimed=E2= =80=9D it can=E2=80=99t be claimed by anyone else without the current = claimant=E2=80=99s authorisation.=20 7. Who is the ultimate controller if there is an immutable initial = bootloader with a trust anchor immutably set, and a stage two bootloader = with another trust anchor, and an application?=20 The immutable initial bootloader creates a firmware update right, i.e. = an ownership right, which has been permanently claimed by whoever set = its trust anchor. In most devices an immutable initial bootloader would = allow updating a stage two bootloader, meaning the stage two = bootloader=E2=80=99s TA can be changed. So whoever set the iniitial = bootloaders' TA controls who gets to install the stage 2 bootloader, and = whoever installs the stage 2 bootloader controls who gets to install the = main application.=20 The ultimate controller a.k.a. owner is whoever set the root TA. What = they control has been determined by whoever designed and installed the = initial bootloader and whoever designed and fabricated the IC running = it, and perhaps whoever designed and manufactured the device running the = IC. In this case the owner gets to decide who can install the second = boot stage - probably themselves 8. Isn=E2=80=99t is possible to dream up IoT devices that don=E2=80=99t = have logical controllers?=20 I guess so - you could do without secure boot and expose unauthenticated = interfaces, or you could make a device that is always claimable - but = that doesn't invalidate the concept.=20 9. What does transfer of ownership mean then? Setting someone else=E2=80=99s TA in the initial bootloader.=20 10. What if a hacker obtains arbitrary code execution? They 0wn the device but they don=E2=80=99t own it - not unless they can = make their control permanent across reboots. They have application layer = logical control until a reboot.=20 Thanks Amyas From nobody Thu Nov 5 09:43:34 2020 Return-Path: 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 338C23A1935 for ; Thu, 5 Nov 2020 09:43:34 -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 WwzQ-KiCtoO3 for ; Thu, 5 Nov 2020 09:43:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422E83A1919 for ; Thu, 5 Nov 2020 09:43:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EBDA938C7E; Thu, 5 Nov 2020 12:43:37 -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 Wd6AX5hBjxsi; Thu, 5 Nov 2020 12:43:37 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5608C38C6A; Thu, 5 Nov 2020 12:43:37 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E4EE926; Thu, 5 Nov 2020 12:43:29 -0500 (EST) From: Michael Richardson To: "Amyas Phillips\, Ambotec" , "iotops\@ietf.org" In-Reply-To: References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:43:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Amyas Phillips, Ambotec wrote: > Most IoT devices are > now sold with EULAs, constraining any remaining legal concept of > ownership with contractual terms. > You can even find that a licence > to use it is the only thing you get when you buy a device, legal title > remaining with the vendor. Yes. Many people have problems with this, but ideally, this state of things woul= d be more explicit. I think that, if explained clearly, that many entities would refuse to "license" the device. > I=E2=80=99d like to suggest that we set aside legal title and say =E2= =80=9Cownership=E2=80=9D > for the purpose of this discussion means =E2=80=9Clogical control of a > device=E2=80=9D. Transfer of logical control is an important and deli= cate event > in an IoT device=E2=80=99s lifecycle so this seems to fit within the = aims of > the charter, even if it isn=E2=80=99t mentioned explicitly. > I=E2=80=99d like to further suggest that logical control ultimately m= eans the > right to control what software is installed on a device. That is to > say, ownership =3D=3D logical control =3D=3D the right to set and (if= transfer > of control is supported) replace the firmware update trust anchor. Th= at > is what ownership means. Every other form of control is delegated from > that and is called something other than =E2=80=9Cownership". This definition works for me. > 1. What if an IC has an integrated secure element under logical contr= ol > of a third party and it is impossible even for a person with legal > title to seize control of that SE? > That=E2=80=99s fine, just acknowledge the SE as a separate domain of > control. Someone has physical title, possibly constrained by license > terms. Someone has logical control of the SE. Someone has logical > control of the =E2=80=98insecure=E2=80=99 computing environment. It w= ould a similar > situation in a device with a main application processor and separate a > wireless module with its own firmware. > 2. Wouldn=E2=80=99t this mean that any device whose firmware has to b= e signed > by its OEM is still under the logical control of and =E2=80=9Cowned= =E2=80=9D by that > OEM? > Yes. Agreed. > 3. But that=E2=80=99s not who I mean when I talk about the owner! > I get it, but this just means different and more specific terminology > is required. You might mean the entity trusted by the device to issue > application-layer commands (possibly including commands to set > application-layer trust anchors). Agreed. > 6. What if the device ships without trust anchors, who owns it then? > It is in a first-to-claim state. That assumes that once =E2=80=9Cclai= med=E2=80=9D it > can=E2=80=99t be claimed by anyone else without the current claimant= =E2=80=99s > authorisation. Or, maybe it can't be updated, and it's first-malware-to-claim :-) > 8. Isn=E2=80=99t is possible to dream up IoT devices that don=E2=80= =99t have logical > controllers? > I guess so - you could do without secure boot and expose > unauthenticated interfaces, or you could make a device that is always > claimable - but that doesn't invalidate the concept. Are you, in "always claimable", including the case that the device manufacturer will delegate software signing to the legal physical owner? Apparently, many enterprises demand the right to control what and when updates are deployed, and thus this has become a thing in SUIT. > 9. What does transfer of ownership mean then? > Setting someone else=E2=80=99s TA in the initial bootloader. !yup. > 10. What if a hacker obtains arbitrary code execution? > They 0wn the device but they don=E2=80=99t own it - not unless they c= an make > their control permanent across reboots. They have application layer > logical control until a reboot. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+kOcEACgkQgItw+93Q 3WUA9Af/QKW06MQ/AfP4835fBG5GeY24C+AhebG9d6nM2sVkMQA+esCmce1SFcg5 zcXa4xZNGpfWg1LLRsOaDlVGUPnMDJGqkCbpNkkxRrA63l8oYAacOd38AZKnmaZm xyGYZv3H9LVfBBVlJ676Dm+hmEAYkWNhQhASVZgkwxvGhvQ0ChOb9UkgL5+hCSEg ExotrAwYPqCK3q9Bhoafyj6+DI73N50G73YZuyMOy5K8d5li/yBaOM9aUCySu1xt PKInedCqL2ZGtiMUlYZ8c+WFQas7yQ1D4KrGy7va4feJc72hz2whlgOpd2aYyxvt OW+K2BG0fcGqBJ4lYUsmfqNlOjeGhw== =RZhA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 5 11:43:17 2020 Return-Path: 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 3B2CD3A19E3 for ; Thu, 5 Nov 2020 11:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Z-sLTijx8u9M for ; Thu, 5 Nov 2020 11:43:13 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C0D3A19E0 for ; Thu, 5 Nov 2020 11:43:13 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id h6so2053010pgk.4 for ; Thu, 05 Nov 2020 11:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QzzYaE3IupQ0IjQoNs4dlcnOuAsQVcVA0bofRNgcPIc=; b=gZGjyNXoeTOJt7B/4I2HEsC8oPuj8Gyg0C+jsQdmteNRjqMOLVffGNG4O/SpH0p+Jm q/OGtbpvt05MiYFAk8+A9NMBzRDCXxC+5DB/PEi+/MHx7VYjDJNsUUZnPhjnu8O27Xy2 YEzFO4HbbVXq1gagbKsjH49h76J9R8pt/MVg9NZfr9AmU8vSh9KIfZu6Rs+uQNtkValZ 4EBhkTY54Nm+iVgr1l1SbN57VmQa++rCLMfQAU9PF2Fx4EekHpf08KIQul7hRNEbiicU undT53RgieXYREwBtgcrDS6WGgn97c5Rc0xmeYeFIWKi/5Zowc/gtKxqJGnRajVmqNo1 K7LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QzzYaE3IupQ0IjQoNs4dlcnOuAsQVcVA0bofRNgcPIc=; b=H4cZcvNcwcIg/gEFYWCgJ3dmf0sO3Snti6pyo2NXcHXS5bz9ZzSln8znMJOfALL7ew 6ochP8CQo3dfmC4FWuopO8zSITcZuGTZqkkQFT+xsCCGUmAuDblV6BHanUGMywALaWuP pX69s6J+7MIxbq7BGrC2BH/Bc9eVjdQGJAvAe9INwXhCdqG2BV7106mvKZPqyXe3xF07 gDtJkNeUiOzuq4IkeYUUwUV8bYn4goEn1EsXRNE+m5iACcGT4ETbdPWfL7+IK54vqTnY JSe5HX4a/w8MCooBXc8cIwjCcTufo9fOKX7/8prISKO3+qLK2rq/T+3bDnx5TTKGi+Re 4yaQ== X-Gm-Message-State: AOAM531X9+a6cO4XZn3pVd7rjzpVJoUJh/jQj3r7IvuHasdMDUJEEFdt XU1qQOdQv4md2AulJlCzgz2Mm7nowhZ2gA== X-Google-Smtp-Source: ABdhPJxtO93HBdTEREQxQPtwRj7ponoo8XvBdmRFaIOHiElyIf1voQ5OHf1quZCldmI6xpi0za9img== X-Received: by 2002:a17:90a:9741:: with SMTP id i1mr793245pjw.139.1604605391794; Thu, 05 Nov 2020 11:43:11 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id v24sm2895609pjh.19.2020.11.05.11.43.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 11:43:10 -0800 (PST) To: Michael Richardson , "Amyas Phillips, Ambotec" , "iotops@ietf.org" References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> <20562.1604598209@localhost> From: Brian E Carpenter Message-ID: <45ed90d2-28ad-0726-2ce6-1b92a4fd9712@gmail.com> Date: Fri, 6 Nov 2020 08:43:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20562.1604598209@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] maintain ownership X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 19:43:15 -0000 On 06-Nov-20 06:43, Michael Richardson wrote: >=20 > Amyas Phillips, Ambotec wrote: > > Most IoT devices are > > now sold with EULAs, constraining any remaining legal concept of > > ownership with contractual terms. >=20 > > You can even find that a licence > > to use it is the only thing you get when you buy a device, legal = title > > remaining with the vendor. >=20 > Yes. > Many people have problems with this, but ideally, this state of things = would be more explicit. > I think that, if explained clearly, that many entities would refuse to > "license" the device. >=20 > > I=E2=80=99d like to suggest that we set aside legal title and say= =E2=80=9Cownership=E2=80=9D > > for the purpose of this discussion means =E2=80=9Clogical control= of a > > device=E2=80=9D. Transfer of logical control is an important and = delicate event > > in an IoT device=E2=80=99s lifecycle so this seems to fit within = the aims of > > the charter, even if it isn=E2=80=99t mentioned explicitly. >=20 > > I=E2=80=99d like to further suggest that logical control ultimate= ly means the > > right to control what software is installed on a device. That is = to > > say, ownership =3D=3D logical control =3D=3D the right to set and= (if transfer > > of control is supported) replace the firmware update trust anchor= =2E That > > is what ownership means. Every other form of control is delegated= from > > that and is called something other than =E2=80=9Cownership". >=20 > This definition works for me. It's attractive, but it leaves me with one concern. The concept of "owner= ship" implies the concept of "theft". If ownership is defined in this new way, what is the equivalent definition of theft? How do we know that the entit= y with logical control really has the right to that control? How do we know that control has been stolen? I don't mean that this is a show-stopper, but it does mean that the new definition chases its own tail to some extent. Brian >=20 > > 1. What if an IC has an integrated secure element under logical c= ontrol > > of a third party and it is impossible even for a person with lega= l > > title to seize control of that SE? >=20 > > That=E2=80=99s fine, just acknowledge the SE as a separate domain= of > > control. Someone has physical title, possibly constrained by lice= nse > > terms. Someone has logical control of the SE. Someone has logical= > > control of the =E2=80=98insecure=E2=80=99 computing environment. = It would a similar > > situation in a device with a main application processor and separ= ate a > > wireless module with its own firmware. >=20 > > 2. Wouldn=E2=80=99t this mean that any device whose firmware has = to be signed > > by its OEM is still under the logical control of and =E2=80=9Cown= ed=E2=80=9D by that > > OEM? >=20 > > Yes. >=20 > Agreed. >=20 > > 3. But that=E2=80=99s not who I mean when I talk about the owner!= >=20 > > I get it, but this just means different and more specific termino= logy > > is required. You might mean the entity trusted by the device to i= ssue > > application-layer commands (possibly including commands to set > > application-layer trust anchors). >=20 > Agreed. >=20 > > 6. What if the device ships without trust anchors, who owns it th= en? >=20 > > It is in a first-to-claim state. That assumes that once =E2=80=9C= claimed=E2=80=9D it > > can=E2=80=99t be claimed by anyone else without the current claim= ant=E2=80=99s > > authorisation. >=20 > Or, maybe it can't be updated, and it's first-malware-to-claim :-) >=20 > > 8. Isn=E2=80=99t is possible to dream up IoT devices that don=E2=80= =99t have logical > > controllers? >=20 > > I guess so - you could do without secure boot and expose > > unauthenticated interfaces, or you could make a device that is al= ways > > claimable - but that doesn't invalidate the concept. >=20 > Are you, in "always claimable", including the case that the device > manufacturer will delegate software signing to the legal physical owner= ? > Apparently, many enterprises demand the right to control what and when > updates are deployed, and thus this has become a thing in SUIT. >=20 > > 9. What does transfer of ownership mean then? >=20 > > Setting someone else=E2=80=99s TA in the initial bootloader. >=20 > !yup. >=20 > > 10. What if a hacker obtains arbitrary code execution? >=20 > > They 0wn the device but they don=E2=80=99t own it - not unless th= ey can make > > their control permanent across reboots. They have application lay= er > > logical control until a reboot. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T cons= ulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 From nobody Thu Nov 5 13:03:47 2020 Return-Path: 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 095FB3A1A43 for ; Thu, 5 Nov 2020 13:03:46 -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 YFwJDqimWp4Y for ; Thu, 5 Nov 2020 13:03:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A893A1A47 for ; Thu, 5 Nov 2020 13:03:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E229738C7D; Thu, 5 Nov 2020 16:03:50 -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 r4I5RGK7A2Nb; Thu, 5 Nov 2020 16:03:50 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C42C38C7C; Thu, 5 Nov 2020 16:03:50 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 68B827B; Thu, 5 Nov 2020 16:03:42 -0500 (EST) From: Michael Richardson To: Brian E Carpenter , "Amyas Phillips\, Ambotec" , "iotops\@ietf.org" In-Reply-To: <45ed90d2-28ad-0726-2ce6-1b92a4fd9712@gmail.com> References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> <20562.1604598209@localhost> <45ed90d2-28ad-0726-2ce6-1b92a4fd9712@gmail.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 Archived-At: Subject: Re: [Iotops] maintain ownership X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 21:03:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> Amyas Phillips, Ambotec wrote: >> > Most IoT devices are >> > now sold with EULAs, constraining any remaining legal concept of >> > ownership with contractual terms. >> >> > You can even find that a licence >> > to use it is the only thing you get when you buy a device, legal t= itle >> > remaining with the vendor. >> >> Yes. >> Many people have problems with this, but ideally, this state of thin= gs would be more explicit. >> I think that, if explained clearly, that many entities would refuse = to >> "license" the device. >> >> > I=E2=80=99d like to suggest that we set aside legal title and say = =E2=80=9Cownership=E2=80=9D >> > for the purpose of this discussion means =E2=80=9Clogical control = of a >> > device=E2=80=9D. Transfer of logical control is an important and d= elicate event >> > in an IoT device=E2=80=99s lifecycle so this seems to fit within t= he aims of >> > the charter, even if it isn=E2=80=99t mentioned explicitly. >> >> > I=E2=80=99d like to further suggest that logical control ultimatel= y means the >> > right to control what software is installed on a device. That is to >> > say, ownership =3D=3D logical control =3D=3D the right to set and = (if transfer >> > of control is supported) replace the firmware update trust anchor.= That >> > is what ownership means. Every other form of control is delegated = from >> > that and is called something other than =E2=80=9Cownership". >> >> This definition works for me. > It's attractive, but it leaves me with one concern. The concept of "o= wnership" > implies the concept of "theft". If ownership is defined in this new w= ay, > what is the equivalent definition of theft? How do we know that the e= ntity > with logical control really has the right to that control? How do we > know that control has been stolen? It's a definite tussle between ownership and pwnership. > I don't mean that this is a show-stopper, but it does mean that the n= ew > definition chases its own tail to some extent. Legal code often is non-deterministic when executed on different "CPUs" :-) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+kaK4ACgkQgItw+93Q 3WW66gf/WGIafzy9dC/QiKz7LsAUfaOFgdQKMqIKcqbQyTYLYRzQgVbIv8EDxGye Zcmk6KB/IHfetlZzBJdjqU0qkbN7OUYsYMf7zKiY34HIMjxEYEm8ZB3WkOH5FQAC DVq6dITJilAioIuxnVWMd18wQYx9b1Wc1pOuj78WCFnLQ+qzuh4Nw4qF0XmpWGTQ k282lwJuimQh5QoNmwhRMZ7S0daTBrT+OaYPjQM2CkCDg/nlo8pZ25xvBKd/rBa9 KRIlC3BwVUe6NxryjgpixRyIMA0bAQIcybSL3shbpDS+qZAQ/KW/ynUws4Qfn5SK Ae8CeRoksLIiKuZzcWeRHzJ3Q2ovJw== =6St8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 6 00:01:19 2020 Return-Path: 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 3E78C3A0E81 for ; Fri, 6 Nov 2020 00:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 DMgS6WCPA4ey for ; Fri, 6 Nov 2020 00:01:16 -0800 (PST) Received: from rgout04.bt.lon5.cpcloud.co.uk (rgout0403.bt.lon5.cpcloud.co.uk [65.20.0.216]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9C3A0E7C for ; Fri, 6 Nov 2020 00:01:16 -0800 (PST) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddtkedguddujecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefvkfgjfhfugggtfghihfffsegrtdersgdtreejnecuhfhrohhmpeghihhllhhirghmpgflpgfiucfqvhgvrhhinhhgthhonhcuoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeevleffieeivdelveelkefgkeetgeejleejteelledvffdvffdtveefudeuvedvgeenucfkphepuddtrdduuddtrdduvddrvddpkeeirdduheekrdduledrfeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepfigvsghmrghilhdvkedrsghtrdgvgihtrdgtphgtlhhouhgurdgtohdruhhkpdhinhgvthepuddtrdduuddtrdduvddrvddpmhgrihhlfhhrohhmpeeofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehiohhtohhpshesihgvthhfrdhorhhgqe Received: from webmail28.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout04.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5C55FFA9190C7AA6 for iotops@ietf.org; Fri, 6 Nov 2020 08:01:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604649676; bh=ORP8ePlMibVz0pK9L7pARR+E6hfz/FBfIPHKnUJKjrs=; h=To:Message-ID:In-Reply-To:References:Subject:MIME-Version:From:Date; b=uEF4teYmJ6AWQCGym4hew0hTPITJongLvYeKwbKIeLTFHVgUNUcOece0EHy7YOVH+fTOsuQTl0/DsnYFw4jFNw5rff3pRJSWjyKoN9wGDZ4H33oZNlSebKArsyXq9bRnvNJ+qOjqo1OJ+EGPeNF6rZQlT5/cbb0hhx6EKwnj6h8= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Fri, 6 Nov 2020 08:01:08 +0000 To: iotops@ietf.org Message-ID: <3bfc23ab.47.1759c92d025.Webtop.219@btinternet.com> In-Reply-To: <4613.1604610222@localhost> References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> <20562.1604598209@localhost> <45ed90d2-28ad-0726-2ce6-1b92a4fd9712@gmail.com> <4613.1604610222@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_545_871659704.1604649668552" User-Agent: OWM Mail 3 X-SID: 219 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Fri, 6 Nov 2020 08:01:08 +0000 (GMT) Archived-At: Subject: Re: [Iotops] maintain ownership X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 08:01:18 -0000 ------=_Part_545_871659704.1604649668552 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Would it help if we defined new words, such as, for example, logconship (coined from parts of 'logical control ownership') and we define them precisely and permanently and publish the definitions and deposit them with dictionaries, legal deposit libraries such as The British Library and The Library of Congress and use the words precisely and exactly? We could define several new words, how ever many we consider necessary, and never change the meanings once defined. If a different meaning, no matter how slightly different, is needed then a new word would be defined and maybe some of the older words would drift out of use except in a historical context. William Overington Friday 6 November 2020 ------=_Part_545_871659704.1604649668552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Would it help if we defined new words, such as, f= or example, logconship (coined from parts of 'logical control ownership= ') and we define them precisely and permanently and publish the definit= ions and deposit them with dictionaries, legal deposit libraries such as Th= e British Library and The Library of Congress and use the words precisely a= nd exactly?

We could define several new words, how ever many we co= nsider necessary, and never change the meanings once defined.

If a= different meaning, no matter how slightly different, is needed then a new = word would be defined and maybe some of the older words would drift out of = use except in a historical context.

William Overington

Fr= iday 6 November 2020

------=_Part_545_871659704.1604649668552-- From nobody Fri Nov 6 01:29:09 2020 Return-Path: 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 E9E1B3A0FCB for ; Fri, 6 Nov 2020 01:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 G3L0a6sDswFt for ; Fri, 6 Nov 2020 01:29:07 -0800 (PST) Received: from rgout03.bt.lon5.cpcloud.co.uk (rgout0303.bt.lon5.cpcloud.co.uk [65.20.0.209]) by ietfa.amsl.com (Postfix) with ESMTP id 963CC3A0FC9 for ; Fri, 6 Nov 2020 01:29:06 -0800 (PST) X-OWM-Source-IP: 10.110.12.1 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddtledgtdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepvffkjghfufggtggfihfhffesrgdtregstderjeenucfhrhhomhephghilhhlihgrmhgplfgpifcuqfhvvghrihhnghhtohhnuceofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepveevgfduudevffeivdeuhefhudduvdefgfdvleeileehveehkeeguefhheeludehnecuffhomhgrihhnpehglhhosggrlhhnvghtrdgtohdruhhknecukfhppedutddruddutddruddvrddupdekiedrudehkedrudelrdefjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeifvggsmhgrihhlfedvrdgsthdrvgigthdrtghptghlohhuugdrtghordhukhdpihhnvghtpedutddruddutddruddvrddupdhmrghilhhfrhhomhepoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeoihhothhophhssehivghtfhdrohhrgheq Received: from webmail32.bt.ext.cpcloud.co.uk (10.110.12.1) by rgout03.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5D42B51907DE1587 for iotops@ietf.org; Fri, 6 Nov 2020 09:29:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604654946; bh=dpAIAFneiOkWsm6rTI84iS/5pLhbkcqHqgVAxA2+5O0=; h=To:Message-ID:In-Reply-To:References:Subject:MIME-Version:From:Date; b=n7AG3mADvczxWv5gk1dWsykzJhVGHClLvq2/GdhwWgoWPg10YPuk/krKLLaVnn2aTe+uV5QIllvfFBWRN6dAbAhDXyh4aPZiJW2ZMLBgbL8tur/mrbCag1SPMxsfs1nkId2mbd1Wk/swuchRyVD120G9cukfLIYVAyTQZLFiTAg= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Fri, 6 Nov 2020 09:29:04 +0000 To: iotops@ietf.org Message-ID: <5aa50f43.f6.1759ce350e5.Webtop.219@btinternet.com> In-Reply-To: <3bfc23ab.47.1759c92d025.Webtop.219@btinternet.com> References: <15665.1604430085@localhost> <20201103204823.GE48111@faui48f.informatik.uni-erlangen.de> <5254.1604514609@localhost> <20562.1604598209@localhost> <45ed90d2-28ad-0726-2ce6-1b92a4fd9712@gmail.com> <4613.1604610222@localhost> <3bfc23ab.47.1759c92d025.Webtop.219@btinternet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1599_1228265469.1604654944391" User-Agent: OWM Mail 3 X-SID: 219 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Fri, 6 Nov 2020 09:29:04 +0000 (GMT) Archived-At: Subject: Re: [Iotops] maintain ownership X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 09:29:09 -0000 ------=_Part_1599_1228265469.1604654944391 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > We could define several new words, how ever many we consider > necessary, and never change the meanings once defined. An End User Licence Agreement (EULA) can cause problems. I have no experience of EULAs with Internet of Things devices, but my experiences with EULAs in relation to fonts may be of interest and have resonance with EULAs for Internet of Things devices. One of the great design features of some computer operating systems, including Windows 10, is that most applications use fonts from a central fonts folder on the computer. So when I am using the Serif PagePlus desktop publishing software to produce a PDF (Portable Document Format) document I can use any appropriately licenced font that is in the fonts folder of my home computer. So I often use Goudita SF, a rather nice Venetian-style font bundled with PagePlus, a font based upon a typeface used by Nicolas Jenson in Venice in the 1470s. There are lots of fonts out there and I would happily buy some of them, but the problem is often the EULAs. This is because I have a small webspace and I like to upload PDF documents that I produce with fonts embedded within them and make them free to read, no registration required, so I have no knowledge of how many copies, if any, are read by people accessing them on the web. The EULAs often want really high licence fees for known quantities of web accesses, and so I just cannot afford that and also I have no way of counting downloads and the net effect is that, no matter how good the design, I just do not buy or use the font because of the terms of the EULA. So, I only use fonts supplied with the software or with other software from Serif, a few generously-offered open source fonts, and some fonts that I have produced myself using the High-Logic software programs FontCreator and Scanahand. http://www.users.globalnet.co.uk/~ngo/ So maybe we need to have a new word, sanseulaship, from "sans (without) eula ownership". This would be pronounced with 'sans' as in sands without the 'd', eula pronounced 'yoo-la' and ship as in 'ownership, thus four syllables, san(d)s - yoo - la - ship. Example sentences: This company will only purchase sanseulaship devices. The sanseulaship policy of the manufacturer has increased the sales of its devices and their widespread deployment. A word that I coined, telesoftware, is now in the Oxford English Dictionary. The coining of new words to encapsulate new meanings is entirely acceptable and part of the way that the English language evolves and develops over time. If the word sanseulaship is to be useful and become used we need a precise definition to be produced and agreed by this group, then published and sent to some dictionaries and to some legal deposit libraries. . William Overington Friday 6 November 2020 ------=_Part_1599_1228265469.1604654944391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> We could define several new words, how = ever many we consider necessary, and never change the meanings once defined= .
<= br/>An End User Licen= ce Agreement (EULA) can cause problems.

I have no experience of EULAs with Internet of Things = devices, but my experiences with EULAs in relation to fonts may be of inter= est and have resonance with EULAs for Internet of Things devices.
One of the great design feat= ures of some computer operating systems, including Windows 10, is that most= applications use fonts from a central fonts folder on the computer.=

So when I am using the Se= rif PagePlus desktop publishing software to produce a PDF (Portable Documen= t Format) document I can use any appropriately licenced font that is in the= fonts folder of my home computer.

So I often use Goudita SF, a rather nice Venetian-style fon= t bundled with PagePlus, a font based upon a typeface used by Nicolas Jenso= n in Venice in the 1470s.

There are lots of fonts out there and I would happily buy some of th= em, but the problem is often the EULAs. This is because I have a small webs= pace and I like to upload PDF documents that I produce with fonts embedded = within them and make them free to read, no registration required, so I have= no knowledge of how many copies, if any, are read by people accessing them= on the web. The EULAs often want really high licence fees for known quanti= ties of web accesses, and so I just cannot afford that and also I have no w= ay of counting downloads and the net effect is that, no matter how good the= design, I just do not buy or use the font because of the terms of the EULA= .
<= br/>So, I only use fo= nts supplied with the software or with other software from Serif, a few gen= erously-offered open source fonts, and some fonts that I have produced myse= lf using the High-Logic software programs FontCreator and Scanahand.=

http://www.users.globalne= t.co.uk/~ngo/

So ma= ybe we need to have a new word, sanseulaship, from "sans (without) eul= a ownership". This would be pronounced with 'sans' as in sands= without the 'd', eula pronounced 'yoo-la' and ship as in &= #39;ownership, thus four syllables, san(d)s - yoo - la - ship.
<= font style=3D"background-color: rgb(255, 255, 255);">
Example sentences:
<= font style=3D"background-color: rgb(255, 255, 255);">
This company will only purchase= sanseulaship devices.

The sanseulaship policy of the manufacturer has increased the sales of = its devices and their widespread deployment.

A word that I coined, telesoftware, is now in the= Oxford English Dictionary. The coining of new words to encapsulate new mea= nings is entirely acceptable and part of the way that the English language = evolves and develops over time.

If the word sanseulaship is to be useful and become used we ne= ed a precise definition to be produced and agreed by this group, then publi= shed and sent to some dictionaries and to some legal deposit libraries.
.
= William Overington

= Friday 6 November 202= 0

------=_Part_1599_1228265469.1604654944391-- From nobody Fri Nov 6 08:06:07 2020 Return-Path: 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 CF21E3A07CE; Fri, 6 Nov 2020 08:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 UQ_HbrNohsJc; Fri, 6 Nov 2020 08:06:05 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E4B3A07C4; Fri, 6 Nov 2020 08:06:03 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 58ED8548658; Fri, 6 Nov 2020 17:05:58 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 502E7440059; Fri, 6 Nov 2020 17:05:58 +0100 (CET) Date: Fri, 6 Nov 2020 17:05:58 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, netconf@ietf.org, iotops@ietf.org Message-ID: <20201106160558.GA48249@faui48f.informatik.uni-erlangen.de> References: <19352.1604423135@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <19352.1604423135@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] [Anima] what to call different RFC8366 format artifacts X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 16:06:07 -0000 I like FOO-signed-BAR better because it reminds readers whose life does not enter around FOO or BAR what this is about (signed object). Maybe some time there are different options how FOO can sign BAR, then we may need to add additional distinctions On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote: > > Hi, RF8366 specifies a YANG module for a voucher, and the format as > serialized to JSON, and signed by CMS. > > In section 5.4, it is written: > > 5.4. CMS Format Voucher Artifact > The IETF evolution of PKCS#7 is CMS [RFC5652]. A **CMS-signed voucher**, > > In section 8.3, it is written: > Encoding considerations: *CMS-signed JSON* vouchers are ASN.1/DER > encoded. > > So it became natural for me to write "CMS-signed-JSON". > In development of RFC8366, we argued for using JOSE rather than CMS, but > there were, at the time (2016) lack of familiarity with JOSE, and concerns > about having FIPS-140 validation of that code. > > In draft-ietf-anima-constrained-voucher, we introduce two new things: > 1) signing with COSE > 2) encoding with CBOR. > > A number of people have written, rather than "CMS-signed-JSON", instead, > "JSON in CMS". I wondered at the BRSKI design team call last Thursday if > perhaps that order of words translates better into Dutch or German, or ??? > > So to bikeshed the whole thing, please comment on preference in naming: > > 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. > 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. > 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. > 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. > > I note that for some of these "signed" is redundant. > We do not have COSE-signed-JSON, or JWS-signed-CBOR. > > Which feels more natural to you? > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Nov 6 14:21:23 2020 Return-Path: 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 CE3A23A0DCF; Fri, 6 Nov 2020 14:21:17 -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, SPF_HELO_NONE=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 AqBtTNN6GAxF; Fri, 6 Nov 2020 14:21:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24673A0DCD; Fri, 6 Nov 2020 14:21:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CFE538C6E; Fri, 6 Nov 2020 17:21: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 i7ZLn4L1EM9H; Fri, 6 Nov 2020 17:21:25 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AFBFF38C5D; Fri, 6 Nov 2020 17:21:25 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C28C8E7; Fri, 6 Nov 2020 17:21:13 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker , IETF Discussion Mailing List CC: iotops@ietf.org In-Reply-To: References: <1234528e-ef29-e81e-6c47-7bd4abb6fd53@necom830.hpcl.titech.ac.jp> <20201105064427.GV1464@straasha.imrryr.org> <6040f2fc-0c78-b4c2-cf07-43d52f8e8589@necom830.hpcl.titech.ac.jp> 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 Archived-At: Subject: Re: [Iotops] Quantum computing practically impossible X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 22:21:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > breaking X25519 available within one or even two decades. But unlikel= y is > not the same as proven beyond doubt to be impossible. > * It is therefore prudent to consider means of hardening an infrastru= cture > so that it is resilient to quantum cryptanalysis. One of critical things that we (the IETF and IoT community) need to do is show that we have all the tooling required to do Hash-Based Signature Algorithm updates for SUIT (RFC8778). A fire-drill in essence. We don't need to it well, but we need to be able to do that. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+lzFkACgkQgItw+93Q 3WWSVAf/S5dM4cvYQ9xgLim0laB+MQ5OHcOIZmMw+QJaG5yCW6DXKA5GiRxIg3bd mx8IUfPct50XvKKL4il5km/vWFGzbZKvQULB6bxO2klTNGKqOLjZciCXqf9nUSXz X8gKekH2seUPPf8RBJBZHOtCKWKW3L8pGoK5MBVKzRXhcFvz8zdGwwWUQb5tDvVU u89n0kuFLCl+wlt61Qh6DbIHs1GwkfrMqutVO2Ww9XeZq6iXSn8jel4FuZhXEsWw /rBj3pFAjRBF1jaH+S7gw8mD5ALPkPUmdcmgJps95EKJ0g+8S0vuyCXm7o5s+Pzf rNENXE1jrBtBJ/JoUat90bxFztl3Mw== =Qoao -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 8 02:17:48 2020 Return-Path: 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 602303A0317 for ; Sun, 8 Nov 2020 02:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 UXCWIS9UhRpn for ; Sun, 8 Nov 2020 02:17:45 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 59C253A02C1 for ; Sun, 8 Nov 2020 02:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604830664; d=isode.com; s=june2016; i=@isode.com; bh=fyR0nqo+CcO7ySBvPl3umlO6UQ2culOzAGSBED+jovs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=mM9qPMMkctju7VYT4StMYzx8hjiO+jscvXEwGd/Mj0JPm1Emh4tdxmSHWA6GT62S97Jdea TqH1JvSDgPGltcQlCMjl6t8Rb3jt5+FshxOC66/y3iwXl9QkS8WK2U1Jtp4H+yekrKFwed Y17wQqsDGihODjkUwlBcKpqAuoG/fwM=; Received: from [192.168.0.2] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 8 Nov 2020 10:17:44 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <31244.1604425849@localhost> Date: Sun, 8 Nov 2020 10:17:41 +0000 Cc: "Rob Wilton (rwilton)" , "iotops@ietf.org" Message-Id: <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.com> References: <31244.1604425849@localhost> To: Michael Richardson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 10:17:46 -0000 Hi Michael, > On 3 Nov 2020, at 17:50, Michael Richardson wrote:= >=20 > To me, the point was to deal with the lifecycle issues of IoT. > That's one the list in point (1) was about. If the proposed WG to work on lifecycle issues: do you think these would be e= xtensions to protocols done elsewhere in IETF, new protocols or something el= se? Thank you, Alexey= From nobody Wed Nov 11 16:54:38 2020 Return-Path: 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 474273A1281 for ; Wed, 11 Nov 2020 16:54:37 -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 uqe0MVjmLUBo for ; Wed, 11 Nov 2020 16:54:35 -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 24AD63A1280 for ; Wed, 11 Nov 2020 16:54:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E1D8389B6; Wed, 11 Nov 2020 19:55:04 -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 j63PxrQsJqS3; Wed, 11 Nov 2020 19:55:04 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DF7B5389B5; Wed, 11 Nov 2020 19:55:03 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B739F34A; Wed, 11 Nov 2020 19:54:32 -0500 (EST) From: Michael Richardson To: Alexey Melnikov , "Rob Wilton \(rwilton\)" , "iotops\@ietf.org" In-Reply-To: <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.com> References: <31244.1604425849@localhost> <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.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 Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 00:54:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexey Melnikov wrote: >> On 3 Nov 2020, at 17:50, Michael Richardson = wrote: >> >> To me, the point was to deal with the lifecycle issues of IoT. >> That's one the list in point (1) was about. > If the proposed WG to work on lifecycle issues: do you think these > would be extensions to protocols done elsewhere in IETF, new protocols > or something else? Well, all three. I think that the WG should first look for available existing protocols. Said protocols might need profiles and/or new code points to deal with the specific situation. Such a document could occur in an active WG, if one exists, but it could be that the WG is no longer alive. I feel it very unlikely that there would be new protocols from scratch. But, say, some variation of webdav to do configuration management/updates? Or a YANG module? Or an extension to the CAPPORT API? (assuming that WG co= ncludes) A document giving a series of EAT (RATS) claims? Under "something else", I would include adopting work that has occured in some industry-specific vertical, under the whole "Informational 1.0", and "IETF Change-Controlled 2.0" pattern. Plus, of course, the handful of MUD extensions, and another handful of IoT focused BRSKI extensions. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+sh8gACgkQgItw+93Q 3WXHRAgAsgkjjyohHD7QCuFvq4XrDI0VZCTJlysnLU1N9rjiJ3Lx+Fjg0bZG0IBD OBVFNwzyq6eBIIETriTnxC9Ka1MozAVWv/buwr1z0L4VOYBsm22zsuYzm9A/Ij/V V1FVSgq4yBG5XYKbsHZjH7j07wKs09vChk8w/ruRG7nyNyBSUVcy+0bggG+LFZ1a 3ONOwAHHl9EkSBrtPahvskbmoMufd8vxgGc7ktNigQ4YaC+JQcfgb4ROxv9PejWy 4KKaLieel7jLlGTumx94kTlt6+vRKb4QT06dmnSdP37EJcffSomx2azvRr0n+qMt 74VK6XOGTsX+ZAOk7FZDdnv+jh+0Lg== =SvDz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 11 17:34:49 2020 Return-Path: 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 49E223A130F for ; Wed, 11 Nov 2020 17:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 lKNg74PrboUZ for ; Wed, 11 Nov 2020 17:34:42 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91033A1308 for ; Wed, 11 Nov 2020 17:34:41 -0800 (PST) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CWkd71TQqz67HTF; Thu, 12 Nov 2020 09:33:15 +0800 (CST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 12 Nov 2020 02:34:39 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 12 Nov 2020 09:34:37 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 12 Nov 2020 09:34:37 +0800 From: "Panwei (William)" To: Michael Richardson , Alexey Melnikov , "Rob Wilton (rwilton)" , "iotops@ietf.org" Thread-Topic: [Iotops] IOTOPS Draft Charter Thread-Index: Adax30q2qgoRJah6TfKWMxRovMp5tP//zwiAgAddDoCABav7AP//bv2Q Date: Thu, 12 Nov 2020 01:34:37 +0000 Message-ID: References: <31244.1604425849@localhost> <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.com> <26359.1605142472@localhost> In-Reply-To: <26359.1605142472@localhost> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.99.125] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Iotops] IOTOPS Draft Charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 01:34:48 -0000 KzENCg0KUmVnYXJkcyAmIFRoYW5rcyENCldlaSBQYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBJb3RvcHMgW21haWx0bzppb3RvcHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gUmljaGFyZHNvbg0KPiBTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMTIsIDIwMjAgODo1NSBBTQ0KPiBUbzogQWxleGV5IE1lbG5pa292IDxhbGV4ZXkubWVs bmlrb3ZAaXNvZGUuY29tPjsgUm9iIFdpbHRvbiAocndpbHRvbikNCj4gPHJ3aWx0b25AY2lzY28u Y29tPjsgaW90b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSW90b3BzXSBJT1RPUFMgRHJh ZnQgQ2hhcnRlcg0KPiANCj4gDQo+IEFsZXhleSBNZWxuaWtvdiA8YWxleGV5Lm1lbG5pa292QGlz b2RlLmNvbT4gd3JvdGU6DQo+ICAgICA+PiBPbiAzIE5vdiAyMDIwLCBhdCAxNzo1MCwgTWljaGFl bCBSaWNoYXJkc29uDQo+IDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiAgICAgPj4N Cj4gICAgID4+IFRvIG1lLCB0aGUgcG9pbnQgd2FzIHRvIGRlYWwgd2l0aCB0aGUgbGlmZWN5Y2xl IGlzc3VlcyBvZiBJb1QuDQo+ICAgICA+PiBUaGF0J3Mgb25lIHRoZSBsaXN0IGluIHBvaW50ICgx KSB3YXMgYWJvdXQuDQo+IA0KPiAgICAgPiBJZiB0aGUgcHJvcG9zZWQgV0cgdG8gd29yayBvbiBs aWZlY3ljbGUgaXNzdWVzOiBkbyB5b3UgdGhpbmsgdGhlc2UNCj4gICAgID4gd291bGQgYmUgZXh0 ZW5zaW9ucyB0byBwcm90b2NvbHMgZG9uZSBlbHNld2hlcmUgaW4gSUVURiwgbmV3DQo+IHByb3Rv Y29scw0KPiAgICAgPiBvciBzb21ldGhpbmcgZWxzZT8NCj4gDQo+IFdlbGwsIGFsbCB0aHJlZS4N Cj4gDQo+IEkgdGhpbmsgdGhhdCB0aGUgV0cgc2hvdWxkIGZpcnN0IGxvb2sgZm9yIGF2YWlsYWJs ZSBleGlzdGluZyBwcm90b2NvbHMuDQo+IFNhaWQgcHJvdG9jb2xzIG1pZ2h0IG5lZWQgcHJvZmls ZXMgYW5kL29yIG5ldyBjb2RlIHBvaW50cyB0byBkZWFsIHdpdGggdGhlDQo+IHNwZWNpZmljIHNp dHVhdGlvbi4gIFN1Y2ggYSBkb2N1bWVudCBjb3VsZCBvY2N1ciBpbiBhbiBhY3RpdmUgV0csIGlm IG9uZQ0KPiBleGlzdHMsIGJ1dCBpdCBjb3VsZCBiZSB0aGF0IHRoZSBXRyBpcyBubyBsb25nZXIg YWxpdmUuDQo+IA0KPiBJIGZlZWwgaXQgdmVyeSB1bmxpa2VseSB0aGF0IHRoZXJlIHdvdWxkIGJl IG5ldyBwcm90b2NvbHMgZnJvbSBzY3JhdGNoLg0KPiBCdXQsIHNheSwgc29tZSB2YXJpYXRpb24g b2Ygd2ViZGF2IHRvIGRvIGNvbmZpZ3VyYXRpb24NCj4gbWFuYWdlbWVudC91cGRhdGVzPw0KPiBP ciBhIFlBTkcgbW9kdWxlPyAgT3IgYW4gZXh0ZW5zaW9uIHRvIHRoZSBDQVBQT1JUIEFQST8gKGFz c3VtaW5nIHRoYXQNCj4gV0cgY29uY2x1ZGVzKSBBIGRvY3VtZW50IGdpdmluZyBhIHNlcmllcyBv ZiBFQVQgKFJBVFMpIGNsYWltcz8NCj4gDQo+IFVuZGVyICJzb21ldGhpbmcgZWxzZSIsIEkgd291 bGQgaW5jbHVkZSBhZG9wdGluZyB3b3JrIHRoYXQgaGFzIG9jY3VyZWQgaW4NCj4gc29tZSBpbmR1 c3RyeS1zcGVjaWZpYyB2ZXJ0aWNhbCwgdW5kZXIgdGhlIHdob2xlICJJbmZvcm1hdGlvbmFsIDEu MCIsIGFuZA0KPiAiSUVURiBDaGFuZ2UtQ29udHJvbGxlZCAyLjAiIHBhdHRlcm4uDQo+IA0KPiBQ bHVzLCBvZiBjb3Vyc2UsIHRoZSBoYW5kZnVsIG9mIE1VRCBleHRlbnNpb25zLCBhbmQgYW5vdGhl ciBoYW5kZnVsIG9mIElvVA0KPiBmb2N1c2VkIEJSU0tJIGV4dGVuc2lvbnMuDQo+IA0KPiAtLQ0K PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8gTyAoIElQ djYgScO4VA0KPiBjb25zdWx0aW5nICkNCj4gICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUg V29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0K From nobody Thu Nov 19 05:03:59 2020 Return-Path: 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 AB3183A0E27; Thu, 19 Nov 2020 05:03:54 -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 0Juj0moT6zyR; Thu, 19 Nov 2020 05:03:52 -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 CE44B3A0E08; Thu, 19 Nov 2020 05:03:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F174C389D1; Thu, 19 Nov 2020 08:04:48 -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 WKnrgaOcaTuo; Thu, 19 Nov 2020 08:04:48 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CEA3389CD; Thu, 19 Nov 2020 08:04:48 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DC0CA18B; Thu, 19 Nov 2020 08:03:48 -0500 (EST) From: Michael Richardson To: Esko Dijk , Ted Lemon , Manuel Amutio , "dnssd\@ietf.org" , iotops@ietf.org In-Reply-To: References: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.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 Archived-At: Subject: [Iotops] persistence of naming/identities across "factory" resets (wasRe: [dnssd] Review of draft-ietf-dnssd-srp-05) X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:03:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This thread from dnssd, CCed to iotops. Esko Dijk wrote: > I think many factory resets are done to resolve =E2=80=98error=E2=80= =99 conditions in > products. It is often part of a vendor=E2=80=99s troubleshooting rout= ine, to > get the product back to a well-defined state. Especially for IoT type > products that don=E2=80=99t have much user-specific data stored insid= e this can > work well. An IoT device vendor could in this case make the > public/private key persist across factory-resets of the device; that > would be the most elegant option. Users that reset a device for this > reason would typically expect to get the same name back again (at lea= st > at UI level =E2=80=93 this may or may not be equal to the SRP registe= red name=E2=80=A6) This is actually a pretty big architectural issue. I strongly think that we need to be able qualify the different kinds of factory resets, and we probably need to be able to interrogate a device as = to what kind of reset it just made. We also need to be able to backup device configuration and identity info a number of different encrypted ways. This is in support of devices that need to be repaired, but afterward should continue identically. Possibly that means using the same private keys. Possibly the private keys need to be *removed* before being sent out for repair, and then restored afterwards. Possibly also in some cases we need to be able to force a new identity on t= he device (because it was resold). We need to be do this generically across different device types without need a per-device "APP" > In case the IoT device is designed to generate a new keypair then the > consequence would be that the device can=E2=80=99t claim the same nam= e again, > if the SRP server still has the entry stored. So I assume it will try= a > new name then. > Don=E2=80=99t think that the SRP draft needs to go into these (design= ) details > though, doing any of above scenarios should be feasible for a product. I agree that SRP need not go into it. It would be nice if we could explain these different device models in a way that a future version of SRP could normatively reference. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+2bTQACgkQgItw+93Q 3WW/1AgAi1k5KISyaXl4zn2jJlwoIzlgn3Aw10Amd16rD/gwSEmqXcLrNezwrEgM Q7RuyBq5P+/nFyIqhQZcL8JUStBUwzzn+pgErjVGJm//b5fUOgC/B2B75kl+0HCm 6EieYJbXpJ1ZqxLRl+KzfAA0m02V8ws6pVa23KxbhiQ5l+9NI+VyHImsrhIxfjpf wD4eFD4D1uWP0h0SZ8QYry4fSswjEwPFey/wKASPUGOFTnqptkCTJUImwZpVPlrJ wAnEmSeOfn0O8vf9JGlKtVv2M3WiDYhgAetVLfHcD1Qq1UWK2tKp2kmsI5ftYByN o84mUgLBWdEASqocv22vjcxLgfWqDQ== =GhQm -----END PGP SIGNATURE----- --=-=-=--