From nobody Thu Oct 22 10:19:34 2020 Return-Path: X-Original-To: iotops@ietf.org Delivered-To: iotops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C773A0948; Thu, 22 Oct 2020 10:19:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" Cc: iotops@ietf.org, warren@kumari.net, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <160338716989.22551.17761888498316049460@ietfa.amsl.com> Date: Thu, 22 Oct 2020 10:19:29 -0700 Archived-At: Subject: [Iotops] New Non-WG Mailing List: IOTOPS -- IOT Operations X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:19:30 -0000 A new IETF non-working group email list has been created. List address: iotops@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/iotops/ To subscribe: https://www.ietf.org/mailman/listinfo/iotops Purpose: This list is for the discussion of the proposed IOTOPS WG. This WG will be for the discussion of operational issues related to Internet of Things (IoT) devices and the publication and standardization of documents that relate to management of IoT devices, in particular related to device onboarding and lifecycle management. Link to proposed WG: https://datatracker.ietf.org/wg/iotops/about/ For additional information, please contact the list administrators. From nobody Fri Oct 30 08:04:20 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 ED02F3A1495 for ; Fri, 30 Oct 2020 08:04:11 -0700 (PDT) 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 4wZHW0xTCszh for ; Fri, 30 Oct 2020 08:04:10 -0700 (PDT) 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 F232D3A10E5 for ; Fri, 30 Oct 2020 08:03:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D469A389BE for ; Fri, 30 Oct 2020 11:10:08 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XGDVQSH5Xkne for ; Fri, 30 Oct 2020 11:10:07 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D279A389BB for ; Fri, 30 Oct 2020 11:10:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F3C76617 for ; Fri, 30 Oct 2020 11:03:17 -0400 (EDT) From: Michael Richardson To: 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] making IOTOPS like MOPS... 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, 30 Oct 2020 15:04:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In today's (Oct.30) IOT-DIR meeting, Rob, Warren, Barry and Eric explained = that the IOTOPS group would be more discussion based rather than protocol based. This is inspired from the experience with MOPS. As a result the proposal not moving the MUD extensions and BRSKI extensions from OPSAWG and ANIMA (respectively) to this proposed WG. =2D-- While I am enthusiastic about having a place where IoT work is attracted to, and may even perform some kind of dispatch activity, I still think that the= re is a lot of IoT specific work (and coordination) that is needed. I am writing this email during the discussion, and I look forward to seeing= a revised charter. =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+cKzUACgkQgItw+93Q 3WWe0ggAwObL1R0iU04u5qCuzqh+iYvruXoES7hHtjYBEmQ40rbMaOtS5H/vs2OX d81oTZGcOkpYFyTVAJ/IzDKUdCTFKyjm43G/4Cmj/q5DFxQZvcS7O32bx8TrkLAc V5YLT7ZgWG878Y+C2QjQav2I91WrtPuK78MPiUHnT8HlN9TcSfKv0nki7ldSJpPN EtmArU/x4HLmZ8brdlp/Lgye3RUWSJ87aR8dJZJVOA8q6K9+7wzBwKU9OJ5Dgi5v mTtfBHAbtoqnlK+al35HUMB3msdtHrXomC58RWu8WtlfV5cGlU8UNQb/FepmI0ul lW8HDn0PUfEvO51vDqmObLlBILmjkg== =/cfC -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 30 08:53: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 1AB323A0CD5 for ; Fri, 30 Oct 2020 08:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 (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 Tpq9ecWpvoat for ; Fri, 30 Oct 2020 08:53:55 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 7E69A3A0C7E for ; Fri, 30 Oct 2020 08:53:55 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id i21so4501780qka.12 for ; Fri, 30 Oct 2020 08:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5kDOndK7KQQKCmdw3SMv4uhxpftYxfLMrYGgPmSCQ4A=; b=e7qTDnV3P+IsWnBEkqH2gfTc7i8N9Rty7wQZ04zLOQMCoubbveTR3eLaLqGTcxAob5 pufStbaJdCtzZrK3vvIFXUIYNxZxORTIkz7yGDaVaARgfOu3ZkAGdTHDGH6tAz6Yxdoo 30VA8tUbzIBF2EBjv9OvZxjzpoEoWsTVqwW29pIbnxAYpb+vC2iyA4Fw6ytds1rOIj1l Uy/czINmLSWDcLu1qY7vQ9hLGZRs/YMJHMPmiaGOH/p3vzJ2O9kjOIDvtd9ZwDJZDFbk BOHxryUunZEvq4JH56X8R35Mw66uicb9u7fKszmHmAXGRMqM3Zwwg8SR/Q7VfaI4EAx/ IakQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5kDOndK7KQQKCmdw3SMv4uhxpftYxfLMrYGgPmSCQ4A=; b=O8kr7zf87/rh/7njRrJZxjdrIaszMBHhHjy/ccXW/lGQkV6n5bO3YmUlX8ZiZqPtZy U29QhEwPbXthlK5WYjD5i8FIrJ3SczZN1mBhnJO0MuE6IUVrO/Z67HCIG40V2LCA3fkZ KhNAg3QnoHSyAROwDXfhNqG9L8AG6xYnDRSXKn3fMpghdV17yAc0EypNgvLAo2bcj1Uz lQaGxy0cF/AKHqdFr5LGCpinQz2JNVM95L3YY8+bqnTcaNR71xuySPbbaSov/0GJ7G9t +fWosIzoApf0lSdnOwlQKYlYGFXUgYgVHxMin/zPOHsgVobEVU4QcIuLW+4kvqYJ+Mgq Xxgg== X-Gm-Message-State: AOAM533KpurmV3/70p75S6hiKHUGXL/I9uEk3yQSzJ2g2UIzEazB9Fb+ 3W9nsoyCjAxDIS/gVmt4f2YI+y3RiaI+wvKnh1oFWZDMqE0= X-Google-Smtp-Source: ABdhPJyfsukGN9QeWnVhsSDEyITz60bL24S+cJ9DpFhaK4Uu0nRkFrwXXfEEZ7Bi0NKGDs+dBBZgiTZGmQ9t5n5FQzE= X-Received: by 2002:a37:87c5:: with SMTP id j188mr2761186qkd.476.1604073234122; Fri, 30 Oct 2020 08:53:54 -0700 (PDT) MIME-Version: 1.0 References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> In-Reply-To: <160338716989.22551.17761888498316049460@ietfa.amsl.com> From: "Andrew G. Malis" Date: Fri, 30 Oct 2020 11:53:43 -0400 Message-ID: To: iotops@ietf.org Content-Type: multipart/alternative; boundary="00000000000050494a05b2e56779" Archived-At: Subject: Re: [Iotops] New Non-WG Mailing List: IOTOPS -- IOT Operations 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, 30 Oct 2020 15:53:57 -0000 --00000000000050494a05b2e56779 Content-Type: text/plain; charset="UTF-8" Now that there seems to be at least a few people on the list, I would like to suggest that this be put into the charter as recommended reading: https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/ Cheers, Andy On Thu, Oct 22, 2020 at 1:20 PM IETF Secretariat wrote: > A new IETF non-working group email list has been created. > > List address: iotops@ietf.org > Archive: https://mailarchive.ietf.org/arch/browse/iotops/ > To subscribe: https://www.ietf.org/mailman/listinfo/iotops > > Purpose: > > This list is for the discussion of the proposed IOTOPS WG. > > This WG will be for the discussion of operational issues > related to Internet of Things (IoT) devices and the publication and > standardization of documents that relate to management of IoT devices, > in particular related to device onboarding and lifecycle management. > > Link to proposed WG: https://datatracker.ietf.org/wg/iotops/about/ > > For additional information, please contact the list administrators. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --00000000000050494a05b2e56779 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now that there seems to be at least a few people on the li= st, I would like to suggest that this be put into the charter as recommende= d reading:


Cheers,
Andy


On Thu, Oct 22, 2020 at 1:20 PM IETF Secretariat <ietf-secretariat@ietf.org> wr= ote:
A new IETF = non-working group email list has been created.

List address: iotops@i= etf.org
Archive: https://mailarchive.ietf.org/arch/browse/= iotops/
To subscribe: https://www.ietf.org/mailman/listinfo/iot= ops

Purpose:

This list is for the discussion of the proposed IOTOPS WG.

This WG will be for the discussion of operational issues
related to Internet of Things (IoT) devices and the publication and
standardization of documents that relate to management of IoT devices,
in particular related to device onboarding and lifecycle management.

Link to proposed WG: https://datatracker.ietf.org/wg/io= tops/about/

For additional information, please contact the list administrators.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--00000000000050494a05b2e56779-- From nobody Fri Oct 30 09:30:21 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 492FE3A0FF6 for ; Fri, 30 Oct 2020 09:30:20 -0700 (PDT) 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 EIg-aUqnkzMS for ; Fri, 30 Oct 2020 09:30:18 -0700 (PDT) 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 5A6973A0FEF for ; Fri, 30 Oct 2020 09:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 05D42389BB; Fri, 30 Oct 2020 12:37:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hoID8PIlRHaL; Fri, 30 Oct 2020 12:37:06 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EB09389B9; Fri, 30 Oct 2020 12:37:06 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 69207362; Fri, 30 Oct 2020 12:30:16 -0400 (EDT) From: Michael Richardson To: "Andrew G. Malis" , iotops@ietf.org In-Reply-To: References: <160338716989.22551.17761888498316049460@ietfa.amsl.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] 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: Fri, 30 Oct 2020 16:30:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrew G. Malis wrote: > Now that there seems to be at least a few people on the list, I would= like > to suggest that this be put into the charter as recommended reading: > https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-futu= re-tale-of-refugees-and-sinister-iot-appliances/ Tales of dystopian machine dominated futures abound. There is an entire subarea of sociology that deals with the counter-cyclical nature of SF. (SF is happy when times are dark, and SF is dystopian when times are good) For those that like to keep up on the latest stupidity, given that you probably aren't reading comp.risks anymore, I suggest: http://www.firemountain.net/mailman/listinfo/dumpsterfire Andrew, I presume that the thing we need to take home from this tale of abusive *DRM* (nothing specific to do with IoT) is that we need real transfer of ownership. That's why the charter proposes to work on issues that include: - factory provisioning of devices - onboarding of devices - administrative control of devices - software/firmware upgrades - end of life management of devices There is a significant tussle between: 1) running the software *you* want on *your* devices 2) running the software that external entity X says is secure Vernor Vinge, in _Rainbows End_, written in 2006, and set in 2025, predicts a world where governments say, "Enough is Enough", and they stop letting anyone other than them decide what software will run on person= al computing devices, and core Internet routers. (X=3Dgovernment above) Sure, you can have as many layers of virtualization as we like (the protagonist's teenage granddaughter sets him up with win95^Wfvwm95), but they control the turtle at the bottom. I coined a term Internet of =C3=98wned Things =3D> I=C3=B8T. This is the set of things where the device can actually be owned by the person who bought it. (vs pwned things, where a hostile owns things) My take: if you can't control what software runs on your toaster^Wthing, th= en you don't really =C3=B8wn it. =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+cP5gACgkQgItw+93Q 3WVkVAgAwvqKXRQlzwpPdR2pENO4tgxJjve58wiuac80pvgRBL0dtS0qHPQIGiIF GLQ/x4JeZ5f+MpWy6zMq2k0cZyT4iJwsqwaTuevqm8qppTwJdGjZeGqgAVg+BTjF P82OnyEa9+YipTwjhqoZT4aylzPGvpZguoc2JcKcUDOjy6r+VrW51B6fOlM3exwX ngvw3+VRJMnpFkRl0A0YVxLgggXkORH6usrExLbqlbrKbJfnPHr8+pj/K2KNdFTc EeiOxg8Tg6BARL0i79JdU2+tS6fo5KiL/AAZ3erK64guHvvNvMW3oiycqqTEwMZA 6yaJfqlkVS34XpcyEpnIeiOR2E2VVw== =7VYH -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 30 09:43:50 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 8D5413A0A62 for ; Fri, 30 Oct 2020 09:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 (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 5NkZRNvNPxlc for ; Fri, 30 Oct 2020 09:43:41 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 839613A07F0 for ; Fri, 30 Oct 2020 09:43:41 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id q199so5377806qke.10 for ; Fri, 30 Oct 2020 09:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GIcPvQJ1aAjlejmRgT0oz4eiS5ZEaT98fVmuwCyz4rI=; b=oc7G/stIZi57DNOymPFCyOkZLqy5UsqrVcessaOUp3zPJaEvZdos/Q7XjcPw8RA/Kf JDUhKlDaRRNzr50k17gzZTMzgRTIK5UFx2Phe9qb3ESnSyb72fRfBl3zR3CHswcB+jcl dyvyJQ7K/UrqbglJK+7OC7dF4Uz6/sY+AaPZeosO5GyjnWa+VzYy+ts98pLybz/wytu7 CoQnWnVPFYwQ23rPz5orjJ+pQS0BCuaYp+a3SB6XfrMAfQwoXhOsXdwoFdwjNrfbO+yE TyyLYG+CkQ8k8nSFCAI0BRUHOXRLj4B8lsDi9mfVtg7OjDji+HoA87BpU3j3w0qSkRa+ FnLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GIcPvQJ1aAjlejmRgT0oz4eiS5ZEaT98fVmuwCyz4rI=; b=ErusxXLhuO5SylzX0Soxvvy6kz5LrBGUbtEGWTxk81UJ6JbbDnPE4SAuwH12l0+T9K MU9lZgVpX3tD+XV1Livr0q7dCmuE2uXwLv463Y3B3SHGVXV4bNX8k7OVbLiUDBVHNPaz rmXd73K6l58x0j7DQL3HzyNPqZ07BTwU5eomy2arcGSN4rNX1PsY3+nCFD0aV91i4Ken QCw/FvTrWNQzE899e/vksy576UQqCG8dhYiDB85e7a/qJuxxpALUzlfZ+4Fj+igvCcuU NlZHmghBzkMcDQa9xecIBrIiyRsGeQcVCLcjd3/nsXTQ3DlWyYjZCajvI9AsjGGA+yyI xvcQ== X-Gm-Message-State: AOAM532OqneMuvvKJILwYBqwxlmmuC0SLCJ2dr4XQfatohTMI2uW2r62 PNKs8VT/0SL+zPkYbpXkRUao4E+eSQZGR3a7NVf99N+b X-Google-Smtp-Source: ABdhPJylj5MgEdPtRKvq91hRfvzolJniNf3/g/vrDbIuNEsp3ey5JgmDqZTv+VSz4Gxvhn0+vnTv3PW5RmJ11YesY9o= X-Received: by 2002:a37:9883:: with SMTP id a125mr3024144qke.430.1604076220537; Fri, 30 Oct 2020 09:43:40 -0700 (PDT) MIME-Version: 1.0 References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> <13731.1604075416@localhost> In-Reply-To: <13731.1604075416@localhost> From: "Andrew G. Malis" Date: Fri, 30 Oct 2020 12:43:29 -0400 Message-ID: To: Michael Richardson Cc: iotops@ietf.org Content-Type: multipart/alternative; boundary="00000000000051603005b2e619ac" 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: Fri, 30 Oct 2020 16:43:45 -0000 --00000000000051603005b2e619ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, Thanks for the dumpsterfire pointer. 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. Cheers, Andy On Fri, Oct 30, 2020 at 12:30 PM Michael Richardson wrote: > > Andrew G. Malis wrote: > > Now that there seems to be at least a few people on the list, I > would like > > to suggest that this be put into the charter as recommended reading= : > > > > https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-t= ale-of-refugees-and-sinister-iot-appliances/ > > Tales of dystopian machine dominated futures abound. There is an entire > subarea of sociology that deals with the counter-cyclical nature of SF. > (SF is happy when times are dark, and SF is dystopian when times are good= ) > For those that like to keep up on the latest stupidity, given that you > probably aren't reading comp.risks anymore, I suggest: > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > Andrew, I presume that the thing we need to take home from this tale of > abusive *DRM* (nothing specific to do with IoT) is that we need real > transfer of ownership. > > That's why the charter proposes to work on issues that include: > - factory provisioning of devices > - onboarding of devices > - administrative control of devices > - software/firmware upgrades > - end of life management of devices > > There is a significant tussle between: > 1) running the software *you* want on *your* devices > 2) running the software that external entity X says is secure > > Vernor Vinge, in _Rainbows End_, written in 2006, and set in 2025, > predicts a world where governments say, "Enough is Enough", and they > stop letting anyone other than them decide what software will run on > personal > computing devices, and core Internet routers. (X=3Dgovernment above) > Sure, you can have as many layers of virtualization as we like (the > protagonist's teenage granddaughter sets him up with win95^Wfvwm95), but > they control the turtle at the bottom. > > I coined a term Internet of =C3=98wned Things =3D> I=C3=B8T. > This is the set of things where the device can actually be owned by the > person who bought it. (vs pwned things, where a hostile owns things) > > My take: if you can't control what software runs on your toaster^Wthing, > then > you don't really =C3=B8wn it. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > --00000000000051603005b2e619ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,

Thanks for the dumpsterfire=C2= =A0pointer.=C2=A0

Yes, in addition to being a good= story, the point is who controls the firmware in our things, and how bad i= t can get not only=C2=A0when the manufacturer=C2=A0enforces DRM, but the go= v't enables the behavior (criminalizing jailbreaking).=C2=A0
=
Or the issues that arise=C2=A0when the manufacturer=C2=A0fai= ls to properly maintain the firmware, or goes out of business.
Cheers,
Andy


On Fri, Oct 30, 202= 0 at 12:30 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Andrew G. Malis <= agmalis@gmail.com> wrote:
=C2=A0 =C2=A0 > Now that there seems to be at least a few people on the = list, I would like
=C2=A0 =C2=A0 > to suggest that this be put into the charter as recommen= ded reading:

=C2=A0 =C2=A0 > https://arstechnica.com/gaming/2020/01/= unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-applianc= es/

Tales of dystopian machine dominated futures abound. There is an entire
subarea of sociology that deals with the counter-cyclical nature of SF.
(SF is happy when times are dark, and SF is dystopian when times are good)<= br> For those that like to keep up on the latest stupidity, given that you
probably aren't reading comp.risks anymore, I suggest:
=C2=A0 http://www.firemountain.net/mailman/= listinfo/dumpsterfire

Andrew, I presume that the thing we need to take home from this tale of
abusive *DRM*=C2=A0 (nothing specific to do with IoT) is that we need real<= br> transfer of ownership.

That's why the charter proposes to work on issues that include:
=C2=A0 - factory provisioning of devices
=C2=A0 - onboarding of devices
=C2=A0 - administrative control of devices
=C2=A0 - software/firmware upgrades
=C2=A0 - end of life management of devices

There is a significant tussle between:
=C2=A0 =C2=A01) running the software *you* want on *your* devices
=C2=A0 =C2=A02) running the software that external entity X says is secure<= br>
Vernor Vinge, in _Rainbows End_, written in 2006, and set in 2025,
predicts a world where governments say, "Enough is Enough", and t= hey
stop letting anyone other than them decide what software will run on person= al
computing devices, and core Internet routers. (X=3Dgovernment above)
Sure, you can have as many layers of virtualization as we like (the
protagonist's teenage granddaughter sets him up with win95^Wfvwm95), bu= t
they control the turtle at the bottom.

I coined a term Internet of =C3=98wned Things =3D> I=C3=B8T.
This is the set of things where the device can actually be owned by the
person who bought it.=C2=A0 (vs pwned things, where a hostile owns things)<= br>
My take: if you can't control what software runs on your toaster^Wthing= , then
you don't really =C3=B8wn it.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [




--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--00000000000051603005b2e619ac-- From nobody Fri Oct 30 10:25:13 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 A6E103A1059 for ; Fri, 30 Oct 2020 10:25:12 -0700 (PDT) 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 Zrsu7TDzKsqy for ; Fri, 30 Oct 2020 10:25:10 -0700 (PDT) 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 77B923A1056 for ; Fri, 30 Oct 2020 10:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 085D7389BB; Fri, 30 Oct 2020 13:31:59 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1OBkVcf5e6Hg; Fri, 30 Oct 2020 13:31:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8897E389BA; Fri, 30 Oct 2020 13:31:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 50826362; Fri, 30 Oct 2020 13:25:08 -0400 (EDT) From: Michael Richardson To: "Andrew G. Malis" , 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: Fri, 30 Oct 2020 17:25:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 main= tain > 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. =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+cTHQACgkQgItw+93Q 3WXpggf+OTf7cccY4LUp06FUNXFSVBOKPV9AQ7Ykp5czxAKuDHN/tHqcnnnKk0tp hDxvVc8kXcejpViJWUUDHMMijCif01v/Ri2V/eICbRySk6aMIPZ6GE0tK5Yk1ML1 VGeEn06d0mZIDZRQAof/zEg4aELVv9AmqgIVX2VXLcvfTvxMZ4KEa0zhoixYVebh M4a7ij3lzk5U/QHT9k+O6OMrFbIpdYc5ypy74Jah+phck5RHa3K29oQwJKBbE8wZ bD6SqQ0D0h5974dRqs3UAi73dKrD15QdXYxxlHmuVMrmwUU9lfVwqvfL73dP8Rsv Q4OOfMHG5vi5ruLYQ4u5PYhheZSwlA== =JNh9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 30 12:58:37 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 763713A11E3 for ; Fri, 30 Oct 2020 12:58:35 -0700 (PDT) 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=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 XrLDJd0fD-Oc for ; Fri, 30 Oct 2020 12:58:33 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 C5AA43A11D4 for ; Fri, 30 Oct 2020 12:58:33 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id r10so3494235plx.3 for ; Fri, 30 Oct 2020 12:58:33 -0700 (PDT) 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=dfOo74FldJ1IiyFqtipotnOqCJ4L3DL4QzoVI38qvMQ=; b=lHSOgolW5Mxn5efHjks3THW9ILTz5cu0JdwZsUl1yExGeRazf5AYYW68KWBxp2tJO2 DAhuPVU9a5p1LczKKm3NY+LNN2tYCSHHs6E4wtDn/ayuiAzZCRqvTfdiwlLGZ2YuRoni wAfEUiebxX4owX/9vCixYd8gMxYTBuCVmVFkk6JhxAbp3KGMhSjpUKr6DT0X8P/xbrqq H1QUOJjwl0o7b2N7m6nuqjiBkZVgnvZ/jGj/+tdnx9eFZ+qvniwV9ca5euVXH6DkJQx1 EF5fBVNYxaYI4IfLw39L33IEBi0Du3b464+/Dg72MswgPend+PrKpko6+Y4F3DYwLFqa 9eYg== 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=dfOo74FldJ1IiyFqtipotnOqCJ4L3DL4QzoVI38qvMQ=; b=Es6wi8btqa5GSksEYuRR/JWCb8kGmzeS2TMAkLKfKIhXtP8+UlF5oDfgvVqykrZDot zDnzp3EwEvOd1EsFs+rgV5Uf+wQVlXg7KhswraF6WvZCVrKFbgWocr+orjrWifzev1Jz QjED/s1ImwEXtLK4zk+YfdqWz+INYZEAUdyoB0f8i/JsDvjEBJnM6gjABzu3Z/4Yy3UV Sq/yABipPU+rOJNHhuew4GsUvEOAjDPolbqI7arOGuBTOVFUbp7rhb4/ByS7t75KFidM JiRJvXWhjpY2NW1d9C119nUK1uaRoZCagfplqEmteeIK618QQDOmrlZRzv37Hzfsim6n xjDQ== X-Gm-Message-State: AOAM530EAn2P+cfXUeitK6LdbkezTP8Fqt7lEADh8nms7mjnWCekiZGL IbUwqavNgTqxSdBE00K7Sp+fTtFecGE= X-Google-Smtp-Source: ABdhPJy5DgLUVMY7ysJ4YUV2OKItBJ+PgjEx/f2KxgOlO4Zw+VTN6xkSJ6rMLYO3+fwvYHR2xacAGQ== X-Received: by 2002:a17:902:21:b029:d2:564a:5dc6 with SMTP id 30-20020a1709020021b02900d2564a5dc6mr10657527pla.14.1604087912859; Fri, 30 Oct 2020 12:58:32 -0700 (PDT) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id w6sm6308891pgr.71.2020.10.30.12.58.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2020 12:58:32 -0700 (PDT) To: Michael Richardson , "Andrew G. Malis" , iotops@ietf.org References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> <13731.1604075416@localhost> <28326.1604078708@localhost> From: Brian E Carpenter Message-ID: <9a2a134a-e530-81de-7c51-e6d401c3c7dd@gmail.com> Date: Sat, 31 Oct 2020 08:58:27 +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: <28326.1604078708@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 30 Oct 2020 19:58:35 -0000 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. Brian From nobody Fri Oct 30 14: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 D9DE73A0962 for ; Fri, 30 Oct 2020 14:03:45 -0700 (PDT) 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 xO08GKoYJKVq for ; Fri, 30 Oct 2020 14:03:43 -0700 (PDT) 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 12F4B3A0924 for ; Fri, 30 Oct 2020 14:03:42 -0700 (PDT) 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 9B404548659; Fri, 30 Oct 2020 22:03:37 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 949F3440059; Fri, 30 Oct 2020 22:03:37 +0100 (CET) Date: Fri, 30 Oct 2020 22:03:37 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , "Andrew G. Malis" , iotops@ietf.org Message-ID: <20201030210337.GK48111@faui48f.informatik.uni-erlangen.de> References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> <13731.1604075416@localhost> <28326.1604078708@localhost> <9a2a134a-e530-81de-7c51-e6d401c3c7dd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a2a134a-e530-81de-7c51-e6d401c3c7dd@gmail.com> 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: Fri, 30 Oct 2020 21:03:46 -0000 On Sat, Oct 31, 2020 at 08:58:27AM +1300, Brian E Carpenter wrote: > On 31-Oct-20 06:25, Michael Richardson wrote: > > > > Andrew G. Malis 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 pricipally 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 claissically did without crypto, namely private networks (with private addresses), we should also have a crypto strategy for such private networks. And in most cases, livetime-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 expirty time (e.g.: infinite). This could be hosted in a private TA. The question is primarily how to have browsers support diffeent 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. JUst a line of thoughts. Cheers Toerless > > Brian > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Sat Oct 31 03:55:37 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 74AB43A0D98 for ; Sat, 31 Oct 2020 03:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 nR2E-9QM-H3L for ; Sat, 31 Oct 2020 03:55:32 -0700 (PDT) Received: from rgout02.bt.lon5.cpcloud.co.uk (rgout0201.bt.lon5.cpcloud.co.uk [65.20.0.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED783A0D9B for ; Sat, 31 Oct 2020 03:55:29 -0700 (PDT) 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: gggruggvucftvghtrhhoucdtuddrgedujedrleejgddvvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefvkffugggtfghihfffsegrtdersgdtreejnecuhfhrohhmpeghihhllhhirghmpgflpgfiucfqvhgvrhhinhhgthhonhcuoeifjhhgohgpuddttddtleessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeduteeggefhjeeghefhtddvteelgfeggeetfeehgeekudevvdfgieevueefvdelkeenucffohhmrghinhepghhlohgsrghlnhgvthdrtghordhukhdpfiiffidrsghlrdhukhenucfkphepuddtrdduuddtrddufedruddpkeeirdduheekrdduledrfeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepfigvsghmrghilhegtddrsghtrdgvgihtrdgtphgtlhhouhgurdgtohdruhhkpdhinhgvthepuddtrdduuddtrddufedruddpmhgrihhlfhhrohhmpeeofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoefkohhtohhpshesihgvthhfrdhorhhgqe Received: from webmail40.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 5B93D594263F8EA5 for Iotops@ietf.org; Sat, 31 Oct 2020 10:55:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1604141732; bh=yov0ab468VhIb3VAcrKlTdYFCc4fEw3hHQeDhDjvnDI=; h=To:Message-ID:Subject:MIME-Version:From:Date; b=MQzDL6rLYtK8bx/z39FQQpVfWZNwSKh4sTnDkx/VeSJLw/Y42ooHYSMQkzk2qJI37w1QARML57U9z9IjgTMU0qxZTZe0kyvcKZAlhF4ZpIH25s5N/cQZePcE2Gn4/ZFax7C5qKWhITQ5m2GA/fV0UA/unBNbu1gsG5OhggxJqD8= Received: from [86.158.19.37] by ux.btmail.bt.com with HTTP; Sat, 31 Oct 2020 10:55:27 +0000 To: Iotops@ietf.org Message-ID: <6e7fc2c3.ccb.1757e4c3e9e.Webtop.227@btinternet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23526_1966067526.1604141727294" User-Agent: OWM Mail 3 X-SID: 227 X-Originating-IP: [86.158.19.37] From: William_J_G Overington Date: Sat, 31 Oct 2020 10:55:27 +0000 (GMT) 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: Sat, 31 Oct 2020 10:55:35 -0000 ------=_Part_23526_1966067526.1604141727294 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Michael Richardson wrote: > Tales of dystopian machine dominated futures abound. Here is a link to a eutopian science fiction novel that I wrote from June 2016 to February 2019. http://www.users.globalnet.co.uk/~ngo/novel.htm It is free to read, no registration required. The novel is intended to support an invention of mine for communication through the language barrier in some circumstances. The invention was originally intended for person to person communication using plain text and also for use on web pages yet could also be used for human to thing communication and for thing to human communication through the language barrier using plain text. Maybe also for thing to thing communication too as my intention is for the invention to be open source for maximum use and interoperability. The science in the novel is real, there is a real research project, for which there are various documents, including a slide show. http://www.users.globalnet.co.uk/~ngo/localizable_sentences_research.htm A second novel is a work in progress. http://www.users.globalnet.co.uk/~ngo/locse_novel2.htm I am wondering if the issue of being able to recover the original software for a thing could be solved by some infrastructure something like it being good practice for the manufacturer of the thing to produce a hexadecimal dump of the software and publish it in a PDF (Portable Document Format) document and for that PDF document to be deposited at The British Library in accordance with the legal deposit regulations together with a note permitting The British Library to supply a copy to anyone for a fee. The document could also be made available on the manufacturer's website, yet legal deposit at The British Library would mean that the document would still be available even if the manufacturer went out of business and the website was no longer available. That would apply to publications published in the United Kingdom. National libraries in other countries may have similar systems. Given that hexadecimal dump maybe that could be used to reset the thing to its original configuration. I put this forward as an idea for discussion in the hope that a useful infrastructure will be developed. https://www.bl.uk/legal-deposit I have previously sent various pure electronic items to The British Library for legal deposit and these have been accepted and an email receipt sent to me. As well as PDF documents I have sent images and fonts that I have produced and published. William Overington Saturday 31 October 2020 ------=_Part_23526_1966067526.1604141727294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Mi= chael Richardson wrote:

> T= ales of dystopian machine dominated futures abound.

Here is a link = to a eutopian science fiction novel that I wrote from June 2016 to February= 2019.

http://www.users.globalnet.co.uk/~ngo/novel.htm

It is = free to read, no registration required.

The novel is intended to sup= port an invention of mine for communication through the language barrier in= some circumstances. The invention was originally intended for person to pe= rson communication using plain text and also for use on web pages yet could= also be used for human to thing communication and for thing to human commu= nication through the language barrier using plain text. Maybe also for thin= g to thing communication too as my intention is for the invention to be ope= n source for maximum use and interoperability.

The science in the no= vel is real, there is a real research project, for which there are various = documents, including a slide show.

http://www.users.globalnet.co.uk/~ngo/loca= lizable_sentences_research.htm


A second novel is a = work in progress.


http://www.users.globalnet.co.uk/~ngo/lo= cse_novel2.htm


I am wondering if the issue of being able t= o recover the original software for a thing could be solved by some infrast= ructure something like it being good practice for the manufacturer of the t= hing to produce a hexadecimal dump of the software and publish it in a PDF = (Portable Document Format) document and for that PDF document to be deposit= ed at The British Library in accordance with the legal deposit regulations = together with a note permitting The British Library to supply a copy to any= one for a fee. The document could also be made available on the manufacture= r's website, yet legal deposit at The British Library would mean that t= he document would still be available even if the manufacturer went out of b= usiness and the website was no longer available.


That woul= d apply to publications published in the United Kingdom.


N= ational libraries in other countries may have similar systems.


Given that hexadecimal dump maybe that could be used to reset the thin= g to its original configuration.


I put this forward as an = idea for discussion in the hope that a useful infrastructure will be develo= ped.


https://www.bl.uk/legal-deposit


= I have previously sent various pure electronic items to The British Librar= y for legal deposit and these have been accepted and an email receipt sent = to me.


As well as PDF documents I have sent images and fon= ts that I have produced and published.


William Overington<= /p>


Saturday 31 October 2020


------=_Part_23526_1966067526.1604141727294-- From nobody Sat Oct 31 04:56: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 9AD783A197C for ; Sat, 31 Oct 2020 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 PiDINh7ya0mo for ; Sat, 31 Oct 2020 04:56:56 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 8731E3A197B for ; Sat, 31 Oct 2020 04:56:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09VBurkY016344 for ; Sat, 31 Oct 2020 12:56:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 716CB202EBA for ; Sat, 31 Oct 2020 12:56:53 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 66757202C85 for ; Sat, 31 Oct 2020 12:56:53 +0100 (CET) Received: from [10.11.240.40] ([10.11.240.40]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09VBuriR023612 for ; Sat, 31 Oct 2020 12:56:53 +0100 To: iotops@ietf.org References: <160338716989.22551.17761888498316049460@ietfa.amsl.com> <13731.1604075416@localhost> From: Alexandre Petrescu Message-ID: Date: Sat, 31 Oct 2020 12:56:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <13731.1604075416@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit 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: Sat, 31 Oct 2020 11:56:58 -0000 'Transferring ownership' - like in selling property to somebody? A contract would be needed, and a notary with an electronic signature. Le 30/10/2020 à 17:30, Michael Richardson a écrit : > > Andrew G. Malis wrote: >> Now that there seems to be at least a few people on the list, I >> would like to suggest that this be put into the charter as >> recommended reading: > >> https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/ > >> > Tales of dystopian machine dominated futures abound. There are also tales of futures dominated by a few oligarchies storing the data. It would be these private interests that dominate the world, via computers, be them Things or information highways. A sort of facebooks extended along certain negative extension lines. In these worlds indeed the person-to-person communication would be needed to avoid negative situations. But 'transferring ownership' would 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. Or maybe 'securely transfer ownership' would be akin to a delegation of identity, under the form of securely allowing somebody to act on one's behalf, a sort of 'delegation of signature'. Delegate signature but maintain control, like in delegating to vote. Alex There is an entire > subarea of sociology that deals with the counter-cyclical nature of > SF. (SF is happy when times are dark, and SF is dystopian when times > are good) For those that like to keep up on the latest stupidity, > given that you probably aren't reading comp.risks anymore, I > suggest: http://www.firemountain.net/mailman/listinfo/dumpsterfire > > Andrew, I presume that the thing we need to take home from this tale > of abusive *DRM* (nothing specific to do with IoT) is that we need > real transfer of ownership. > > That's why the charter proposes to work on issues that include: - > factory provisioning of devices - onboarding of devices - > administrative control of devices - software/firmware upgrades - end > of life management of devices > > There is a significant tussle between: 1) running the software *you* > want on *your* devices 2) running the software that external entity X > says is secure > > Vernor Vinge, in _Rainbows End_, written in 2006, and set in 2025, > predicts a world where governments say, "Enough is Enough", and they > stop letting anyone other than them decide what software will run on > personal computing devices, and core Internet routers. (X=government > above) Sure, you can have as many layers of virtualization as we like > (the protagonist's teenage granddaughter sets him up with > win95^Wfvwm95), but they control the turtle at the bottom. > > I coined a term Internet of Øwned Things => IøT. This is the set of > things where the device can actually be owned by the person who > bought it. (vs pwned things, where a hostile owns things) > > My take: if you can't control what software runs on your > toaster^Wthing, then you don't really øwn it. > > -- ] Never tell me the odds! | ipv6 > mesh networks [ ] Michael Richardson, Sandelman Software Works > | IoT architect [ ] mcr@sandelman.ca > http://www.sandelman.ca/ | ruby on rails [ > > > > > -- Michael Richardson . o O ( IPv6 IøT > consulting ) Sandelman Software Works Inc, Ottawa and Worldwide > > > > >