Subject: [dnssd] Adam Roach's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 20:50:02 -0800

Adam Roach has entered the following ballot position for
draft-ietf-dnssd-prireq-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-prireq/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.2:

>   Information conveyed via multicast messages can be
>   obtained by an on-link attacker, while unicast messages are only
>   available to MITM attackers.

I don’t think this is accurate. Given that many of the environments under
consideration (e.g., airport WiFi) use unencrypted wireless transmission
combined with a captive portal. In these cases, an eavesdropper on the same
channel can snoop on even unicast traffic without mounting an MITM attack.

----------------------------------------------------------------------

General:

The document speaks of randomization of identifiers, including those commonly
used by users to identify which services they want to connect to. While the
current state of affairs may list a directory such as:

•       Adam’s iPhone
•       David’s Google Pixel 3
•       Alice’s Laptop

(allowing me to select something based on its published name)

This document seems to propose a future state where such directories are
instead presented as:

•       {da566203-0320-4604-aa14-f58ae7bea00c}
•       {6c0952a5-a573-4d92-9d4a-a4bc111a35d8}
•       {785bed6b-1355-4e7e-ad57-b5ce27e83e56}

I find it a bit surprising that this document doesn’t include at least a
cursory mention of the difficulty users may have in device rendezvous under
such a scheme and potential solutions to such issues (e.g., using RFID or QR
codes to provide pairing information).

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Mar 2020 23:39:51 -0600

On 3/4/2020 11:22 PM, Christian Huitema wrote:
> On 3/4/2020 8:50 PM, Adam Roach via Datatracker wrote:
> Adam,
> I wonder were in the document you saw that?

It's implicit in the entire subject matter, and quite explicit in 
section 4.2: "Servers must avoid publishing static identifiers such as 
host names or service names.  When those fields are required by the 
protocol, servers should publish randomized values."

> We started this discussion many years ago with a specific protocol
> proposal, which did indeed include presentations such as list of GUIDs.
> However, there was a significant difference: if the publishing device
> was known to you and you had exchanged credentials, then you would see
> the name in the clear, instead of the cryptic text. The initial proposal
> did include ways to enable quick pairing in order to exchange
> credentials, just like you suggest.
>
> It turns out that the DNSSD working group was not ready to standardize a
> protocol like that. The main reasons is that designing such protocols
> requires a number of trade-offs between usability, management, network
> resource and computing resource. An example of trade-off would be
> whether trial decryption was considered OK: it simplifies the design and
> the operation, at the cost of a high computing load. The initial
> proposal was making specific trade-offs, but these did not get consensus.

Sure. I recognize that this document is at a higher level than that, and 
wouldn't expect that level of detail as much as a one- or two-sentence 
treatment (or perhaps a bit more) that captures the general shape of 
such solutions. Specifically _because_ the document says to replace 
server names with "randomized values," I think it's incumbent on it to 
_at least_ mention the issues that arise from doing so, and to vaguely 
wave at how those issues might be addressed (in a non-exhaustive way, 
using examples).

/a

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Mar 2020 21:22:56 -0800

Adam,

That's why we have the document that we have today. We focused on
presenting the privacy requirements, and stayed well clear of proposing
specific solutions. I think we have been thorough. The requirements did
get consensus in the working group.

I expect that we will see proposed solutions in the future. Maybe
several solutions, with different trade-offs. But I also believe that
having well stated requirements is useful, if only to draw attention on
the privacy issues in many current deployments.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 5 Mar 2020 13:52:33 -0800

On 3/4/2020 9:39 PM, Adam Roach wrote:
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

Note that there is a distinction between host names and service names.
One of the privacy issues with DNSSD is that it requires the
participants to publish a host name in MDNS. That host name does not
need to be visible with the list of available services, the service
names are supposed to be self describing. It could be randomized without
creating much usability issues.

> Sure. I recognize that this document is at a higher level than that,
> and wouldn't expect that level of detail as much as a one- or
> two-sentence treatment (or perhaps a bit more) that captures the
> general shape of such solutions. Specifically _because_ the document
> says to replace server names with "randomized values," I think it's
> incumbent on it to _at least_ mention the issues that arise from doing
> so, and to vaguely wave at how those issues might be addressed (in a
> non-exhaustive way, using examples).

I will try to enter a short text along these lines. At a high level,
this is the classic tension between usability and security...

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Mar 2020 11:42:15 -0800

Adam,

I propose adding the following text to 4.2:

      The current DNS-SD user interfaces present the list of discovered
service names to the users,
      and let them pick a service from the list. Using random
identifiers for service names renders
      that UI flow unusable. Privacy-respecting discovery protocols will
have to solve this issue,
      for example by presenting authenticated or decrypted service names
instead of the
      randomized values.

Is that what you expect?

-- Christian Huitema

---

From: Adam Roach <[email-masked]>
Date: Fri, 6 Mar 2020 14:04:00 -0600

>        for example by presenting authenticated or decrypted service names

That satisfies my concern, yes. Thanks!

/a