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

Adam Roach <adam@nostrum.com> Thu, 05 March 2020 05:40 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABC63A0CCE; Wed, 4 Mar 2020 21:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFYRqvE3ibfr; Wed, 4 Mar 2020 21:40:05 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639F43A0CC5; Wed, 4 Mar 2020 21:40:05 -0800 (PST)
Received: from [172.17.121.48] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (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 adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; 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: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.121.48]
To: Christian Huitema <huitema@huitema.net>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnssd-prireq@ietf.org, dnssd-chairs@ietf.org, dnssd@ietf.org, David Schinazi <dschinazi.ietf@gmail.com>
References: <158338380296.29279.16868170788768865688@ietfa.amsl.com> <681d3976-c141-2f7d-51da-40c49dd9de5b@huitema.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <9dbcf43c-cd04-08a2-29e4-d4716922372d@nostrum.com>
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: <681d3976-c141-2f7d-51da-40c49dd9de5b@huitema.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/SdOrpLRzMX01ikdL0Y-JIHUOTwM>
Subject: Re: [dnssd] Adam Roach's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=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 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?


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

/a