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

[Christian Huitema <[e-mail]>]

On 3/4/2020 8:50 PM, Adam Roach via Datatracker wrote:
> 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).

Adam,

I wonder were in the document you saw that?

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.

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