Re: [dnssd] Review of draft-ietf-dnssd-srp-05

[Esko Dijk <[e-mail]>]

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…)

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.

Esko

From: dnssd <[e-mail]> On Behalf Of Ted Lemon
Sent: Thursday, November 19, 2020 11:43
To: Manuel Amutio <[e-mail]>
Cc: [e-mail]
Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05

On Nov 19, 2020, at 5:14 AM, Manuel Amutio <[e-mail]<mailto:[e-mail]>> wrote:
Regarding my first doubt, I still fail to understand how a device which has lost its security material, for instance after a factory reset, could then claim its right to dispose (remove or update) of the service that was created before.

It can’t, and the document doesn’t suggest that it can.

The expectation is that this would be done when the ownership of the object changes, so that it would be deployed in a different context where the name it claimed would not be used.