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

Adam Roach <> Thu, 05 March 2020 05:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DABC63A0CCE; Wed, 4 Mar 2020 21:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yFYRqvE3ibfr; Wed, 4 Mar 2020 21:40:05 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 639F43A0CC5; Wed, 4 Mar 2020 21:40:05 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 0255dvJK097632 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Mar 2020 23:39:58 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1583386799; bh=0+WQO9gQ5ZwxU3vC9Deb1mDXbpCFZsx3gHu6XjfI98k=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ViaK2nPZe8qiM5xtcdQUYNMGFwpsjowbYtAh2f6SVR5Anh7a9VM3gD7dYPcsAlkSr BZnxISC4v4Ocexw065t43/5h/G5TCaJIECCvkpMICbHw09W+9oIyrlh+160OMMXyOg GRGjEtXtN6qmBHhKpk/1qnAvi0JI1m6W7wBvE9hs=
X-Authentication-Warning: Host [] claimed to be []
To: Christian Huitema <>, The IESG <>
Cc:,,, David Schinazi <>
References: <> <>
From: Adam Roach <>
Message-ID: <>
Date: Wed, 4 Mar 2020 23:39:51 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [dnssd] Adam Roach's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2020 05:40:08 -0000

On 3/4/2020 11:22 PM, Christian Huitema wrote:
> 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
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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?

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