search

huitema / dnssd-privreq

3 stars 0 forks source link

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

Open huitema opened 4 years ago

huitema commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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