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

[Michael Richardson <[e-mail]>]

This thread from dnssd, CCed to iotops.

Esko Dijk <[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide