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

Adam Roach <adam@nostrum.com> Fri, 06 March 2020 20:04 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 8F8A93A0926; Fri, 6 Mar 2020 12:04:14 -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 4qDt-v5ZL6Mn; Fri, 6 Mar 2020 12:04:13 -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 506AD3A093A; Fri, 6 Mar 2020 12:04:13 -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 026K462K008620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 6 Mar 2020 14:04:07 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1583525048; bh=pTTiB8kvxjdJuunrAkrvMbvAHmtco2Mz23y/c5GgJSc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=JcBp5XF2WSuFkDYM+lizrEXa/qc1EdgHuTw9ogi8vGrtqq+lWyg4sClXHgVv+vLvr ObDHoNzDJRAUR9+/qpCLm8t2e7uaP5fxONcpGnTkP60JVb2ga0lgSUl3VjfUxdHtwG OzJseYm2mmhxR721g25CNCmpLatkKNe9G5wc4eTY=
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: David Schinazi <dschinazi.ietf@gmail.com>, dnssd@ietf.org, dnssd-chairs@ietf.org, draft-ietf-dnssd-prireq@ietf.org
References: <158338380296.29279.16868170788768865688@ietfa.amsl.com> <681d3976-c141-2f7d-51da-40c49dd9de5b@huitema.net> <9dbcf43c-cd04-08a2-29e4-d4716922372d@nostrum.com> <00c54c9f-de3c-ff14-6dfe-c404b1c6c2f8@huitema.net> <03f6c4bc-f39e-20c6-4801-f42caee1de13@huitema.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <da386950-f959-f5b7-9c78-b783bcd607c3@nostrum.com>
Date: Fri, 6 Mar 2020 14:04:00 -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: <03f6c4bc-f39e-20c6-4801-f42caee1de13@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/Zu689UhVgf_JQajNBMAdZTJViw4>
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: Fri, 06 Mar 2020 20:04:15 -0000

On 3/6/2020 1:42 PM, Christian Huitema wrote:
> Adam,
>
> I propose adding the following text to 4.2:
>
>
>        The current DNS-SD user interfaces present the list of discovered
> service names to the users,
>        and let them pick a service from the list. Using random
> identifiers for service names renders
>        that UI flow unusable. Privacy-respecting discovery protocols will
> have to solve this issue,
>        for example by presenting authenticated or decrypted service names
> instead of the
>        randomized values.
>
> Is that what you expect?


That satisfies my concern, yes. Thanks!

/a