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

[huitema]

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

[huitema]

Clarification on Adam's "cryptic text" issue:

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."

[huitema]

More clarification on the scope of the document:

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