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

From: Manuel Amutio <[email-masked]>
Date: Sun, 8 Nov 2020 21:18:18 +0100

Hi,

I've revised the current version "draft_05" and in general it looks good to
me. I believe that it is an important improvement in the use of automatic
discovery of network services and it is greatly useful for IoT constrained
devices.

Leave my comments below.

Best,
Manuel

/------------- Typos --------------/
Page 9, first paragraph:
"This key pair MUST be unique to the device" is repeated twice.
"+" symbol appears twice.

Page 12, second paragraph:
"Instrructions"

/------------- Doubts -------------/
Page 9, section 2.4.1.1 Service Behavior:
"the key MAY be overwritten as a result of a full reset of the device
(e.g., a "factory reset")"

What happens then?

Page 10, section 2.4.2 Removing published services:
"To remove a service registration, the client retransmits its most recent
update..."
"However, in some cases a client may not have retained sufficient state to
know that some service instance is pointing to a host that it is removing."

Then, how is it able to retransmit an update of something that no longer
knows?

Page 15, section 2.6.2. Sleep Proxy:
This feature conditions the location of SRP Server, right?
If we thought in a Border Router, it would only be useful for external
traffic going through BR, but not for traffic initiated in the mesh
network.
Maybe I have misunderstood it.

Regarding the protocol used, I don't see a clear drawback to not allow
using UDP for the constrained devices. If the DNS service allows it, I
believe that this new protocol should support it too.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2020 16:39:39 -0500

Thank you for the comments, Manuel!

> "+" symbol appears twice.

What I get for manually applying a diff—thanks for catching it! :)

> Page 12, second paragraph:

Got it.

> "the key MAY be overwritten as a result of a full reset of the device (e.g., a "factory reset")"
> 
> What happens then?

Good question. I’ve clarified:

When the device changes ownership, it may be appropriate to erase the old key and install a new one. Therefore the key MAY be overwritten as a result of a full reset of the device (e.g., a "factory reset”)

> "To remove a service registration, the client retransmits its most recent update..." 
> "However, in some cases a client may not have retained sufficient state to know that some service instance is pointing to a host that it is removing."
> 
> Then, how is it able to retransmit an update of something that no longer knows? 

The notion is that an SRP update with just the host information, and with a lease time of zero, will remove all services advertised by that host, even if the SRP client doesn’t enumerate them in the update.

I’ve re-written the text in this paragraph as follows:

SRP clients are normally expected to remove all service instances when removing a host.  However, in some cases a SRP client may not have retained sufficient state to know that some service instance is pointing to a host that it is removing.  An SRP server can assume that all service instances pointing to a host entry that's being removed are no longer valid.  Therefore, SRP servers MAY remove all service instances pointing to a host when a host is removed, even if the SRP client doesn't remove them explicitly.

> If we thought in a Border Router, it would only be useful for external traffic going through BR, but not for traffic initiated in the mesh network. 

Bear in mind that SRP is a general protocol specification, and stub routers, like the Thread border router, are individual use cases. I don’t think there’s any value in implementing sleep proxy service for a Thread border router—Thread already has its own way of handling sleepy end devices.

> Regarding the protocol used, I don't see a clear drawback to not allow using UDP for the constrained devices. If the DNS service allows it, I believe that this new protocol should support it too.

I also think it makes sense to use UDP for SRP registrations.

Anyway, thanks for the comments, I will be updating the draft to address your and Esko’s comments, as well as Jonathan’s comments that followed my previous update, shortly. :)

---

From: Manuel Amutio <[email-masked]>
Date: Thu, 19 Nov 2020 11:14:50 +0100

Thanks for the clarifications Ted.

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.

I understand that, under such circumstances, the device will use another
security material to create a new service which has not to do with the
first one and thus, the first service will be removed by the server when
its lifetime has expired, right?

Best,
Manuel

El mié., 18 nov. 2020 a las 22:39, Ted Lemon (<[email-masked]>) escribió:

> When the device changes ownership, it may be appropriate to erase the old
> key and install a new one. Therefore the key MAY be overwritten as a result
> of a full reset of the device (e.g., a "factory reset”)
>
>
> The notion is that an SRP update with just the host information, and with
> a lease time of zero, will remove all services advertised by that host,
> even if the SRP client doesn’t enumerate them in the update.
>
> SRP clients are normally expected to remove all service instances when
> removing a host.  However, in some cases a SRP client may not have retained
> sufficient state to know that some service instance is pointing to a host
> that it is removing.  An SRP server can assume that all service instances
> pointing to a host entry that's being removed are no longer valid.
> Therefore, SRP servers MAY remove all service instances pointing to a host
> when a host is removed, even if the SRP client doesn't remove them
> explicitly.
>
>
> Bear in mind that SRP is a general protocol specification, and stub
> routers, like the Thread border router, are individual use cases. I don’t
> think there’s any value in implementing sleep proxy service for a Thread
> border router—Thread already has its own way of handling sleepy end devices.
>
> Anyway, thanks for the comments, I will be updating the draft to address
> your and Esko’s comments, as well as Jonathan’s comments that followed my
> previous update, shortly. :)
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2020 05:43:11 -0500

On Nov 19, 2020, at 5:14 AM, Manuel Amutio <[email-masked]> 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.

---

From: Esko Dijk <[email-masked]>
Date: Thu, 19 Nov 2020 11:22:10 +0000

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 <[email-masked]> On Behalf Of Ted Lemon
Sent: Thursday, November 19, 2020 11:43
To: Manuel Amutio <[email-masked]>
Cc: [email-masked]
Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05

On Nov 19, 2020, at 5:14 AM, Manuel Amutio <[email-masked]<mailto:[email-masked]>> 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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Nov 2020 08:03:48 -0500

This thread from dnssd, CCed to iotops.

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

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