[Iotops] persistence of naming/identities across "factory" resets (wasRe: [dnssd] Review of draft-ietf-dnssd-srp-05)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 19 November 2020 13:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) by tuna.sandelman.ca (Postfix) with ESMTP id F174C389D1; Thu, 19 Nov 2020 08:04:48 -0500 (EST)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (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 <mcr+ietf@sandelman.ca>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, Ted Lemon <mellon@fugue.com>, Manuel Amutio <mamutio@kirale.com>, "dnssd@ietf.org" <dnssd@ietf.org>, iotops@ietf.org
In-Reply-To: <AM8P190MB0979A8AF4C5352F4F040D137FDE00@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <CABXuWKtbNjwtVtiRjQwFrF=1WJ6fEUpQaUZz7iNkL4TG260MoA@mail.gmail.com> <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> <CABXuWKvQu7k+MSKq1svQSt=hFO3Hv39ARXCHUo+a2pmt9zdprA@mail.gmail.com> <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.com> <AM8P190MB0979A8AF4C5352F4F040D137FDE00@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 19 Nov 2020 08:03:48 -0500
Message-ID: <15423.1605791028@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/K6C4eDtERJrrtzN3eswMAWC7z_Q>
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 <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 13:03:55 -0000

This thread from dnssd, CCed to iotops.

Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > I think many factory resets are done to resolve ‘error’ conditions in
    > products. It is often part of a vendor’s troubleshooting routine, to
    > get the product back to a well-defined state. Especially for IoT type
    > products that don’t have much user-specific data stored inside 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 least
    > at UI level – this may or may not be equal to the SRP registered name…)

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 the
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’t claim the same name again,
    > if the SRP server still has the entry stored. So I assume it will try a
    > new name then.

    > Don’t 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.

]               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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide