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

Christian Huitema <huitema@huitema.net> Thu, 05 March 2020 05:49 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 558F13A0D42 for <dnssd@ietfa.amsl.com>; Wed, 4 Mar 2020 21:49:20 -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 UFHPLluVXsTI for <dnssd@ietfa.amsl.com>; Wed, 4 Mar 2020 21:49:18 -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 9F1773A0D40 for <dnssd@ietf.org>; Wed, 4 Mar 2020 21:49:18 -0800 (PST)
Received: from xse177.mail2web.com ([66.113.196.177] helo=xse.mail2web.com) by mx17.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1j9iyJ-000724-G6 for dnssd@ietf.org; Thu, 05 Mar 2020 06:23:02 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48XzfR4tt2z54nf for <dnssd@ietf.org>; Wed, 4 Mar 2020 21:22:55 -0800 (PST)
Received: from [10.5.2.15] (helo=xmail05.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 1j9iyF-0002s4-I9 for dnssd@ietf.org; Wed, 04 Mar 2020 21:22:55 -0800
Received: (qmail 11094 invoked from network); 5 Mar 2020 05:22:55 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.46.191]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dschinazi.ietf@gmail.com>; 5 Mar 2020 05:22:55 -0000
To: Adam Roach <adam@nostrum.com>, 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>
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: <681d3976-c141-2f7d-51da-40c49dd9de5b@huitema.net>
Date: Wed, 4 Mar 2020 21:22:56 -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: <158338380296.29279.16868170788768865688@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.177
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.177/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.177/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dyF9K2ilaF/JaNUYHaAo6qpSDasLI4SayDByyq9LIhVIiP5cdP1VLGU GM8I6rvUZkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoeDwbaJnZ2TaZhv/Bk6d8Jj9 EvBvwu01uVCaGVBWGqty3uf9oOQOka4bvFbNreaX2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsYm1aGKgRFqmjZjxZofiz4rd/2UP/7B/SHD6AZyU79M3ryme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8b7S18zzgQJgwn42E45N+5W4nuZrRf7bMi0WRR6pZ+nWQkMYPBFhtPKIhoHCaG4dZZ5 EbGi0w/5bGI17oWaj1Az9Ar5Mj9gjLxJkSFyDPwF0kXw8BMIsfBCWTvqwtHGsGbsxBoFbdIyTZwD 0tTyhMSslmIVTv1Ee5rv7sZ9DmxNJIaPmF/7MAKyW1Kb4FKGpjTuA2wfoLaLPR0PUDBKmG/311+Y GXGxwC97dDVsRSdUqQ2MtuoXMRfSG2WhEZRm53vbAf3t9GP3f3uQJ+ZgQ/bE647lNwN4qOsSZg+f YhVZG3Fpf9P2WwOdPRT3EWlMd754CMBw7+ErSKQN7lw8ITGaNmGHCZF9ZXtfSxIkZLsbHZnckpWa LvahyBjmQxBKOzsmHW0N+NPiHPgn+dyxhvT1Z5EPOIlpyGKEA1x50oTQDUtseoetsROuM82YMzIj 8EU=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/3VYgLNQLFna--gEnjwFhpJWgXn8>
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:49:20 -0000

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