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

Christian Huitema <huitema@huitema.net> Thu, 05 March 2020 21:52 UTC

Return-Path: <huitema@huitema.net>
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 85D7E3A0CA4 for <dnssd@ietfa.amsl.com>; Thu, 5 Mar 2020 13:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 sVJzwJFyXQMm for <dnssd@ietfa.amsl.com>; Thu, 5 Mar 2020 13:52:39 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF42F3A0CBA for <dnssd@ietf.org>; Thu, 5 Mar 2020 13:52:38 -0800 (PST)
Received: from xse435.mail2web.com ([66.113.197.181] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1j9yPw-000azz-G2 for dnssd@ietf.org; Thu, 05 Mar 2020 22:52:34 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48YPcH3RZWz78wC for <dnssd@ietf.org>; Thu, 5 Mar 2020 13:52:31 -0800 (PST)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1j9yPv-0003MU-Bh for dnssd@ietf.org; Thu, 05 Mar 2020 13:52:31 -0800
Received: (qmail 1150 invoked from network); 5 Mar 2020 21:52:30 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.46.191]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-dnssd-prireq@ietf.org>; 5 Mar 2020 21:52:30 -0000
To: Adam Roach <adam@nostrum.com>, 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>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <00c54c9f-de3c-ff14-6dfe-c404b1c6c2f8@huitema.net>
Date: Thu, 5 Mar 2020 13:52:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <9dbcf43c-cd04-08a2-29e4-d4716922372d@nostrum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.197.181
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.13)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dyF9K2ilaF/JaNUYHaAo6qpSDasLI4SayDByyq9LIhVaXLXlT6x3unA pnd4l+Z+e0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoeDwbaJnZ2TaZhv/Bk6d8Jj9 EvBvwu01uVCaGVBWGquc26dvvYwtpC+/b2oO5+al2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsZaZad0VL/QynhFAlbT36L8w1wK8/Yyyr4pYC+V2mZdJwZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwIVUdYndRiyh yQb8o5SNcNSpUco9MJ9ix4aaI27G6iMItK+056Z5kUOVoW5YGpuAIf0MCd6Fdo7XNd/HWQNcEV4v UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azI/QKtgvVN4NQnMxAyK1BYZxMPnetLBJMh51NiRRoHIDC69f9UDVvTRlGqUTwPSaomiK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXptcQ4DMP15GyIZ02OEMWzrvOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/zmP3A95bgzXq9IM7Ctg0YFEFQic>
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 21:52:41 -0000

On 3/4/2020 9:39 PM, Adam Roach wrote:
> 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."

Note that there is a distinction between host names and service names.
One of the privacy issues with DNSSD is that it requires the
participants to publish a host name in MDNS. That host name does not
need to be visible with the list of available services, the service
names are supposed to be self describing. It could be randomized without
creating much usability issues.

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

I will try to enter a short text along these lines. At a high level,
this is the classic tension between usability and security...

-- Christian Huitema