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

[Adam Roach via Datatracker <[e-mail]>]

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