Subject: [dnssd] Review of draft-sctl-advertising-proxy-02

From: Esko Dijk <[email-masked]>
Date: Mon, 22 Nov 2021 14:57:06 +0000

Dear WG/authors,

Here is a review of draft-sctl-advertising-proxy-02. Overall this looks like a useful extension of the SRP server.

*** 1.
reference [MCAST] can be changed to [RFC 9119] now.

*** 2.1
When the client next renews, the service registry informs
   the client of the new name the service registry selected on its
   behalf.  The client can choose to accept that new name, or select a
   new name of its own choosing.
-> This brings up the question how the server (registry) can do this. Maybe this was planned to be added still?  The SRP draft Section 2.2.5.2 just states that the server responds YXDOMAIN. That’s another behavior than what we say here: informing the client of the new name.
That would need some new/additional message or code presumably.

*** 2.1.1

The text in this section suggests that an Advertising Proxy may be configured in one of two 'modes':

  1.  Non-managed namespace; with renaming upon conflicts (default mode; operate as in section 2.1)
  2.  Managed namespace; no renaming upon conflicts (can be configured in some deployments, as needed, as stated in 2.1.1)

It could be helpful to make this more clear by:

  1.  Creating separate subsections for modes 1 and 2 ; e.g. 2.1.1 and 2.1.2.
  2.  Stating that mode 1 is the default
  3.  Stating that mode 2 MAY be implemented in an Advertising Proxy; and if so, it MAY be enabled by an admin.

Networks that use Advertising Proxies
   configured to behave in this way should provide a way to rename the
   device that is suffering the conflict.
-> This looks like a requirement on a 'network' to provide a way to rename a 'device'.  But typically the device picks/selects its own name, or it is commissioned to claim a particular name.   What does the recommendation practically mean, in that case? Do we mean that there should be some setup/commissioning phase procedure in every network to detect conflicts and resolve them by allowing name changes on the devices ? What about conflicts after the installation/commissioning phase?
Or is it only a requirement on the client device to have some means to let an external tool/commissioner change its name?    Or a requirement that the device itself can pick a new name?
It looks like the recommendation here can be made more clear and actionable.

In order to address this problem, it may be advisable to provide with
   a way for the advertising proxy to inform the mDNS service ... detected.
-> can clarify that this is not needed in case of 'mode 1' operation. And that this is a MUST to support 'mode 2' operation.

*** 3

An Advertising Proxy may made data visible to eavesdroppers on the
   configured multicast-capable link(s).
-> Here it would be good to refer to RFC 8882 for an analysis of privacy and security risks of mDNS.  We can mention explicitly that data which was private to the client/server  (e.g. SRP registration over TLS) is now broadcasted in the clear on the mDNS-link.  So it's not "may make data visible" but its core job is to make all that data visible.
Additional consideration/issue here worth mentioning is that the client may not be aware of the fact that its data is going to be sent out via the Advertising Proxy. Because it does not see the difference between a regular SRP server and one with Advertising Proxy.

That said, an SRP client is of course aware that the data about its services is not staying in the server but is meant to be discoverable to any DNS-SD clients. But the fact that now a fully passive eavesdropper can learn this information without doing a query itself would make an attacker less detectable and less traceable so in my opinion still worth mentioning in Section 3.

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]