Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok

Christian Huitema <huitema@huitema.net> Thu, 28 February 2019 01:20 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 DC107130EB3 for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 17:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vNOeX2VS8O-V for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 17:20:47 -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 4ED351277D2 for <dnssd@ietf.org>; Wed, 27 Feb 2019 17:20:47 -0800 (PST)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gzANQ-0002Vk-5F for dnssd@ietf.org; Thu, 28 Feb 2019 02:20:45 +0100
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gzANL-00019P-9o for dnssd@ietf.org; Wed, 27 Feb 2019 20:20:40 -0500
Received: (qmail 26010 invoked from network); 28 Feb 2019 01:20:38 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 28 Feb 2019 01:20:38 -0000
To: dnssd@ietf.org
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAO8oSXkGAErtKQgMGGT+88PY4Y+wJ_6Rz493exaymZ_L8F4FNg@mail.gmail.com> <CAPDSy+68V=rx8cAbVq6rKxNbb9yHisCCPURwHoLKsA179NooLw@mail.gmail.com> <e9b4900d-94e3-c79a-2a72-e2f996663b9d@huitema.net> <CAPDSy+4d27SQCStGzPpzzv=pjGiCM+0df988BesRGHdV_vvteA@mail.gmail.com> <CAO8oSXnXre29hjbNCZ1N7b8VBRMubS1yO5_XXr7VY2yxzNAWGw@mail.gmail.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <CAO8oSX=rWYxkKq0H5dEJDKq_Hs3tH2gqSxQ-Cr_SaHDPkrvvCA@mail.gmail.com> <CAO8oSXkfszNXUT6gr1G2OEWgJXe-cX_S4yAJmLm5sUqN0SQ54w@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
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: <89ab9dfc-99a5-9522-201b-3713abf43575@huitema.net>
Date: Wed, 27 Feb 2019 17:20:37 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAO8oSXkfszNXUT6gr1G2OEWgJXe-cX_S4yAJmLm5sUqN0SQ54w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------FD57F4C37E1EAFC7C94C6EA6"
Content-Language: en-US
X-Originating-IP: 168.144.250.234
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.41)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5mWi9i3IjIwhp+CwgHQZ5iF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxZLpoiQthPIA7cnhPSJaiPFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j52UOCQU2jyl+0Kabky0HVIE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMTc/0DL0kGticgfK7BXdIl5xnsMi381k+gKZDYa33nZ/VUmFvay9hMy UnVRXsIgAwlk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlvU1uY02BpZUH+5G+hilxr1ZYSpQQtCkh8qZ SV0LCxteUezCGZdE0ZiyXGw3Lc2q1KOmMBwjPp11sp1InAaAdOQhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK12Se+z8wGp/D0quA+5xotO9UshveVgoiypAicYsWUtdcKaDTe3QRRhTm1Fh 3Md1t44cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/CQjHDqjSzXU74muKEXduc3Ga7KM>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
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, 28 Feb 2019 01:20:50 -0000

On 2/27/2019 4:45 PM, Christopher Wood wrote:
>> I think this highlights an important difference between the two
>> proposals on the table. Namely, whether or not service discovery
>> happens in one or two RTTs or stages. The design you sketch above
>> permits 1-RTT discovery at the cost of lesser security. (The service
>> ID is not encrypted, thereby permitting dictionary attacks as we
>> discussed.) Bob's proposal addresses this by first doing a mutually
>> authenticated key exchange and then querying for the service in the
>> second trip.
>>
>> While no one was opposed to the two stage approach during the last
>> meeting, I'm not sure we should rule it out. It depends on the threat
>> model.
>>
>> So, having said all that, perhaps someone can take a stab at
>> documenting the threat model here? That might help us choose a
>> solution given a shared understanding of the problem. I'm happy to
>> give it a shot.
> Or perhaps we can short circuit that discussion entirely and simply
> get consensus around the crux of the issue: is the WG comfortable with
> the one stage approach and the possible attack(s), or do we think two
> stages should be used? I'm quite curious to hear what others think.

The service ID is in fact encrypted, ESNI stands for "encrypted SNI".
Clearly, this requires TLS 1.3, to guarantee that the server's
parameters are encrypted -- we would not want the server's certificate
in the clear. But we are looking at a direct connection over a local
network, without expected interference from firewalls and other
middle-boxes.

If we align with TLS, we benefit from all the security analysis done for
TLS, and all the design work done for ESNI. I am looking at doing a
prototype using the Picoquic implementation of QUIC and the Picotls TLS
stack, and I think I could have a demo in Prague -- looks like a great
hackathon project. The work is fairly minimal:

1) At the client, provision the server discovery key out of band at
authorized clients, instead of the DNS lookup of the ESNI key of the
client facing server in the standard implementation;

2) At the server, accept the first packet in the exchange over a
broadcast channel,

3) At the server, discard all ClientHello packets that do have an ESNI
extension demonstrating knowledge of the service discovery key by the
client,

4) At the client, latch on the IP address and port of the response.

The ESNI proposal already has a bunch of provisions for securing the
exchange, such as copying a nonce in the server response to demonstrate
that the server correctly decrypted the ESNI.

-- Christian Huitema