From nobody Mon Jan 1 16:11:16 2018 Return-Path: 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 9AF1B127286 for ; Mon, 1 Jan 2018 16:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yNzHbFUG18BE for ; Mon, 1 Jan 2018 16:11:13 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 130DB127241 for ; Mon, 1 Jan 2018 16:11:11 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id x15so2287345ote.0 for ; Mon, 01 Jan 2018 16:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jbGGQ71ie+2ymp0Ji/S4mAkuhpkL5Jq2LcwKPE3tpt0=; b=hc8lnTkTdJzm+u7IEvsgCDsr/bLwX/49kcmfzYBgpH5JDFBDcAziWyIe1YMBS0pzI4 ctUExvkAO47KiJz9s7fR9Cyu5igIXTj9rHVhgI5NWL3Rgrd5dEon91wmRFaZ+jA5uWhZ NN4rCzN5LtxZ0LbbmfYUdbBBnfBRTUDOeLqr0cjk7DlxeIdYAKlQk3hxjcFvf/IekVj2 yg3Hmn4XSCwSIiesifKcoiFGu6m6rreIcCkcQYUfI5jRni+2qUgCRWp0i9ITMc3tl+jX E7MseLqt8fHzhIAiDycIkJsur6Ue+0fSg9EVl7KmvBXGjKbFIcg1hf5ENFgs8uh5gcVM h81g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jbGGQ71ie+2ymp0Ji/S4mAkuhpkL5Jq2LcwKPE3tpt0=; b=LHFNkeln823uhIsSsTTQyWqYu4UmyFDD+T4zJwEkM+B0V1Pcn0en9qTe/9s1JTYmpy nTBNe1Sj5TJNZ1UcXzP89gxuQRxc6WIB1g141HQgmBnIfGms2C8QCx1E2wvfPTDiFtpQ gzkQ5Nww7SQGNCKIowCO/iiITOSRTrTuz74mUMZfbMPl96W9RXEadvu4DBaWYdVe2h64 UnHwnHH5A0Mp4IKDXbQ6dtXMCvCjv8APA5M4TUPRNccHoPMSWgwnTX+B2onxySZ72EtY x7Zh/MEyNzjFRb15APLsqJm7KH2vfRIwnLuRVUN0OLA2he7C8s1k8zyFPlRb+IQtEsUN d4cA== X-Gm-Message-State: AKGB3mKr+XE7g+ivz+NE4nvf36GSfOVJsTyC8ykhqr6MNQEnsrGFArK+ hS0wt8ZIQI9r3U/QV7YAbA5krJuZGwGdYngYq6qCdQ== X-Google-Smtp-Source: ACJfBouW2a9Oz4vFQXdtRwMo4EYblGKmR4JHX4JTO3WDokExcjSGgrxyfvthJfMtfoGd8OOjO/rTE8dTPYw0e8kT3fU= X-Received: by 10.157.88.42 with SMTP id r42mr40213254oth.71.1514851870219; Mon, 01 Jan 2018 16:11:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 16:11:09 -0800 (PST) In-Reply-To: <4b8fad55-b283-e0fc-4af1-7fcfa4603193@huitema.net> References: <4b8fad55-b283-e0fc-4af1-7fcfa4603193@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 11:11:09 +1100 Message-ID: To: Christian Huitema Cc: dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dnssd] Reviewing DNS-SD privacy issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 00:11:16 -0000 I agree with your analysis regarding granularity. Particularly on mobile platforms, mutual distrust between applications is the benchmark we want to apply. Browsers are already there. On Sun, Dec 31, 2017 at 5:45 AM, Christian Huitema wrote: > I have been reviewing the DNS-SD privacy issues in light of Stuart's > draft (draft-cheshire-dnssd-privacy-considerations-01) and his > presentation at IETF 100 > (https://datatracker.ietf.org/meeting/100/materials/slides-100-dnssd-04-stuart-privacy/). > Draft and presentation reflect uneasiness with several of the design > choices that we made in draft-ietf-dnssd-privacy-03, > draft-ietf-dnssd-pairing-03, and draft-ietf-dnssd-pairing-info-00. I > believe this boils down to three big issues: granularity of trust, type > of secret, and type of pairing agreement. > > Stuart provides a convincing illustration of the granularity issue with > the "implanted insulin monitor" example. In this example, the trust > relation is obviously between the device and the medical application on > the phone, and certainly not with "any gaming application on the phone", > let alone "any device owned by the user". Enforcing this granularity > leads to an "application-centered" design, in contrast with the > device-centered design chosen in draft-ietf-dnssd-privacy. Our two-phase > design is to "privately discover a device, then ask that device for > available services". An application centered device would be just one > phase, "privately discover an application". > > There is little doubt that maintaining privacy requires some type of > trust establishment. In our drafts, we chose to base that trust on > pairwise shared secrets, established through a pairing operation. > Pairwise secrets have the advantage of being easy to understand and > manage, since the secret is shared between just two entities. But > pairwise operation scales at best as O(N), possibly O(N**2). The > alternative may be to use public key technology. This would scale better > when entities have to manage a large number of pairings, such as for > example a printer that can be used by a whole group of people, but it is > pretty hard to establish trust using public keys without disclosing at > least one of the public keys to third parties. This may be OK when one > of the parties does not have privacy concerns. For example, in the group > printer example, it may be OK to disclose the identity of the printer as > long as the identity of the users is kept private. > > The pairing agreement proposed in draft-ietf-dnssd-pairing-03 relies on > a final authentication step, in which a "short authentication string" is > verified. The problem there is not the correctness of the protocol, but > the weakness of the human user. Pairing processes can be long and > convoluted. After the user has finally mastered the UI on two devices > and gone through all the process, it is very tempting to press the "OK" > button without looking too closely to the strings on the displays. > Designs that require to enter a PIN or a password before proceeding with > the pairing do not have that weakness, and technology exist that make > them secure. > > These three arguments have pretty drastic consequences on the design of > "private discovery". They did surface quite late in the process, but I > agree with Stuart that the priority is to get the right standard > published. Our goal should be a standard that is widely deployed and > used. Of the three main issues above, the pairing technology is probably > the easiest to tackle -- moving from SAS to JPAKE and documenting why > would be straightforward. But the other two points deserve extended > discussion. What are the implications of moving from a device focus to > an application focus? Is this just a privacy issue, or does it affect > other aspects of DNS-SD? Can we really provide symmetric privacy with > asymmetric keys? Do we have examples of public-key based algorithms? I > would really like to see a discussion on this list! > > -- Christian Huitema > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Jan 10 08:41:16 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18902126C19; Wed, 10 Jan 2018 08:41:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dnssd@ietf.org, dnssd-chairs@ietf.org, dschinazi@apple.com, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151560247301.18329.8843671719024233388.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 08:41:13 -0800 Archived-At: Subject: [dnssd] dnssd - New Meeting Session Request for IETF 101 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:41:13 -0000 A new meeting session request has just been submitted by David Schinazi, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: David Schinazi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: intarea 6lo dprive homenet dnsop 6man saag v6ops Second Priority: babel ipsecme People who must be present: Tim Chown Terry Manderson David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 10 08:42:25 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4572612D96C; Wed, 10 Jan 2018 08:42:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dnssd@ietf.org, dnssd-chairs@ietf.org, dschinazi@apple.com, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151560254327.18401.10628232597954403955.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 08:42:23 -0800 Archived-At: Subject: [dnssd] dnssd - Update to a Meeting Session Request for IETF 101 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:42:23 -0000 An update to a meeting session request has just been submitted by David Schinazi, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: David Schinazi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: intarea 6lo dprive homenet dnsop 6man saag v6ops anima core Second Priority: babel ipsecme People who must be present: Tim Chown Terry Manderson David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 14 16:47:35 2018 Return-Path: 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 3FDEA12D854 for ; Sun, 14 Jan 2018 16:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 nTZhMYgTMPQv for ; Sun, 14 Jan 2018 16:47:32 -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 90E4F126DED for ; Sun, 14 Jan 2018 16:47:32 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1easvx-0001xf-JY for dnssd@ietf.org; Mon, 15 Jan 2018 01:47:30 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1easvq-0007Lg-Hf for dnssd@ietf.org; Sun, 14 Jan 2018 19:47:26 -0500 Received: (qmail 11697 invoked from network); 15 Jan 2018 00:47:21 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Jan 2018 00:47:21 -0000 To: dnssd@ietf.org References: <4b8fad55-b283-e0fc-4af1-7fcfa4603193@huitema.net> From: Christian Huitema Message-ID: <4f9f4425-1482-b94a-4f7f-1c43974874c1@huitema.net> Date: Sun, 14 Jan 2018 14:47:20 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gaFm2KB0DmVtOm1/jvydDgXv9krsgRhBn0ayn6qsUc7oeDwbaJnZ2Ta Zhv/Bk6d8K1PdOWeIW8R8TgUu5HhPnKRoMYKnfuB7zSI/MJgyXiQTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKdWynZUxsMC1E3ExQzsigr+jj0HlFDoqoWF20+xKQ35+nd/nGlMBQ0xDQkm A/S/XltWjP649SQzhF817kql58kAx71HfxpF/K3Kf4qEIfLm3dpo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c35l4zT/9O3Fa5t/wfTM8Lj3qPsymJWvDwykKJqs6rg CShtfWEBSErP+Z0pzyRxh9Lh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/K9 ZRlGTBNbjFFp2EGWMpOZ6Fd7qWsQvIr61TrKdKGtuHLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dnssd] Reviewing DNS-SD privacy issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 00:47:34 -0000 On 1/1/2018 2:11 PM, Martin Thomson wrote: > I agree with your analysis regarding granularity. Particularly on > mobile platforms, mutual distrust between applications is the > benchmark we want to apply. Browsers are already there. I have entered three issues in GitHub to keep track of various ideas regarding the three points: granularity of trust, type of trust token, and pairing algorithm: * https://github.com/huitema/dnssdprivacy/issues/7: Granularity of trust * https://github.com/huitema/dnssdprivacy/issues/8: Scaling issues with different kinds of trust tokens * https://github.com/huitema/pairing/issues/1: Users might press OK without actually looking at the SAS You are all welcome to add your own comments on these issues, or of course on the mailing list if you prefer. -- Christian Huitema From nobody Sun Jan 14 16:55:41 2018 Return-Path: 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 F41EE12D854 for ; Sun, 14 Jan 2018 16:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zGR8EKPCfJuV for ; Sun, 14 Jan 2018 16:55:38 -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 A4133126DED for ; Sun, 14 Jan 2018 16:55:38 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eat3o-0006jM-4Y for dnssd@ietf.org; Mon, 15 Jan 2018 01:55:37 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eat3k-0007Kl-Jy for dnssd@ietf.org; Sun, 14 Jan 2018 19:55:33 -0500 Received: (qmail 7846 invoked from network); 15 Jan 2018 00:55:31 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Jan 2018 00:55:31 -0000 To: dnssd@ietf.org From: Christian Huitema Message-ID: Date: Sun, 14 Jan 2018 14:55:27 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.70) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5myp8pHROOg/uY4IrgUSC0gXv9krsgRhBn0ayn6qsUc7oeDwbaJnZ2Ta Zhv/Bk6d8K1PdOWeIW8R8TgUu5HhPnIqBZSaVUA0RRfrX/jfaLeOTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5TPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VznEK6Y0Zc8di+RlqaqtTezFdjxqs+aJ4gdrY8aSad lec4CCtvQs64a4e0Oq4D7ygHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFx6MCWuKzfg8cFFqpWFwyxcibYT4C2qF2lnc18bVJn660 xNVR/7sYVVsYFzRIpji2z/3vvjwiMlbod/y+Y0fbRzwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTDgZtJVJVWhfcbC/eCuIKr1jI1dRH6f16eQCtvwPkeoxsvP5n/w7KUFovOTT14a2Sl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [dnssd] DNSSD privacy scaling issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 00:55:40 -0000 We want privacy. That means that the devices will "offer service to some subset of clients", rather than "offer to everybody". But we do not delegate privacy to the infrastructure, so we cannot have solutions in which the infrastructure performs access control. That leaves solution in which the service is "offered to everybody", but only qualified clients understand the "real name" behind the obfuscated name. Hence the general structure: service announces an obfuscated name, typically function of time and secret. Clients will find the available services on the network, and filter out those that they are not interested in. There are two options for the trust token: symmetric key, or asymmetric. In the symmetric version, client and server manage a shared secret. Both client and server can construct the obfuscated name. Server publishes a name, encrypt or hash of time-based nonce with shared key. Clients can also construct a priori the obfuscated names of the servers that they are interested in. Client retrieves all names and check whether some of them match the expected peer list. Or, in server based discovery, client asks server whether obfuscated name is published. The problem there is a tradeoff between scalability and impersonation. If we use the same shared secret for all clients, the protocol scales well, but any authorized client can impersonate the server for all other clients. If we use pairwise secrets, as specified in the current draft, clients cannot impersonate the server for other clients but the protocol complexity increases significantly. In the asymmetric version, client knows the public key of the server. Server constructs the obfuscated instance name by encrypting the a time-based nonce with the private key. Client looks at all available obfuscated names, and attempts to decrypt every available name. This does not scale very well - public key operation times number of keys known to client times number of services present. But... In the asymmetric version, server could also construct an obfuscated service name by encrypting a time-based nonce with the public key. Client can also construct the obfuscated service name, because it knows the public key. It can look for that name, and normally only finds one instance of the server. It can verify that this is the right server by decrypting the obfuscated name. So we get a privacy respecting discovery system in which the server publishes exactly one record, and the client typically accesses exactly one record per service/server that it discover= s. From nobody Sun Jan 14 17:08:19 2018 Return-Path: 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 4755612D942 for ; Sun, 14 Jan 2018 17:08:17 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 GgEa8Ukpcmr0 for ; Sun, 14 Jan 2018 17:08:15 -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 511E712D940 for ; Sun, 14 Jan 2018 17:08:15 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx15.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eatFz-0002rj-Ls for dnssd@ietf.org; Mon, 15 Jan 2018 02:08:12 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eatFy-00052j-9M for dnssd@ietf.org; Sun, 14 Jan 2018 20:08:11 -0500 Received: (qmail 28168 invoked from network); 15 Jan 2018 01:08:07 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Jan 2018 01:08:07 -0000 To: dnssd@ietf.org References: From: Christian Huitema Message-ID: <250af321-a0bb-7119-735d-6545da88a684@huitema.net> Date: Sun, 14 Jan 2018 15:08:07 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.52) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5p0+QGs71DGlhXK/ATIe5H8Xv9krsgRhBn0ayn6qsUc7oeDwbaJnZ2Ta Zhv/Bk6d8K1PdOWeIW8R8TgUu5HhPnIbEJkWf7p+C0zSPKWfqh/PTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKdWpXZEoctxN/zoJa2wa6+xjj0HlFDoqoWF20+xKQ35+nd/nGlMBQ0xDQkm A/S/XltWjP649SQzhF817kql58kAx71HfxpF/K3Kf4qEIfLm3dpo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c3uTDbeuuD7RyXX9xP+P0f0+rz8o+OMH4YIPUlGxVNH elCKv2BSQL6Ky6n1o/ddWfPh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GzCf4c0o7D6gM9WJQM09qxZnHEeB4hpRrmo/duzUUp/Lm dAppSIgUFfrADTYugkxoeFI3SBdsbM99WXFhG1DOOHLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+R4HKWR6SMBqrz1a2dl/GB4j2lB9TLiDMfXuvSrucRXom7I3bwInONPnB4uC7Qfcgpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dnssd] DNSSD privacy scaling issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 01:08:17 -0000 On 1/14/2018 2:55 PM, Christian Huitema wrote: > We want privacy. That means that the devices will "offer service to som= e > subset of clients", rather than "offer to everybody". But we do not > delegate privacy to the infrastructure, so we cannot have solutions in > which the infrastructure performs access control. That leaves solution > in which the service is "offered to everybody", but only qualified > clients understand the "real name" behind the obfuscated name. Hence th= e > general structure: service announces an obfuscated name, typically > function of time and secret. Clients will find the available services o= n > the network, and filter out those that they are not interested in. > > There are two options for the trust token: symmetric key, or asymmetric= =2E > > In the symmetric version, client and server manage a shared secret. Bot= h > client and server can construct the obfuscated name. Server publishes a= > name, encrypt or hash of time-based nonce with shared key. Clients can > also construct a priori the obfuscated names of the servers that they > are interested in. Client retrieves all names and check whether some of= > them match the expected peer list. Or, in server based discovery, clien= t > asks server whether obfuscated name is published. The problem there is = a > tradeoff between scalability and impersonation. If we use the same > shared secret for all clients, the protocol scales well, but any > authorized client can impersonate the server for all other clients. If > we use pairwise secrets, as specified in the current draft, clients > cannot impersonate the server for other clients but the protocol > complexity increases significantly. > > In the asymmetric version, client knows the public key of the server. > Server constructs the obfuscated instance name by encrypting the a > time-based nonce with the private key. Client looks at all available > obfuscated names, and attempts to decrypt every available name. This > does not scale very well - public key operation times number of keys > known to client times number of services present. But... > > In the asymmetric version, server could also construct an obfuscated > service name by encrypting a time-based nonce with the public key. > Client can also construct the obfuscated service name, because it knows= > the public key. It can look for that name, and normally only finds one > instance of the server. It can verify that this is the right server by > decrypting the obfuscated name. So we get a privacy respecting discover= y > system in which the server publishes exactly one record, and the client= > typically accesses exactly one record per service/server that it discov= ers. > In the asymmetric key version, privacy depends on the public key being secret. If it is not, anybody can attempt to decrypt the obfuscated name published by the servers, and check whether the result matches the expected time-based nonce -- we get a "nonce-oracle". Adversaries can collect lists of public keys, and use the oracle to track which servers are advertising on a given network. Treating the public key as a shared secret between the server and authorized clients does significantly simplify the protocol: "authorization to discover" simply means access to the public key. As we saw above, we can use a nonce encrypted with the public key (or hashed with the public key) as a service identifier. Maybe add the actual service name in the mix if several services are managed using the same public key. Note that using the same key for all clients does not diminish privacy compared to a solution that uses just bilateral secrets. The real secret is the identity, presence and location of the server, and that secret can be discovered by any authorized client. If just one client is compromised, the server privacy is compromised, and having separate secrets for each client won't change that. -- Christian Huitema From nobody Tue Jan 16 11:14:53 2018 Return-Path: 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 B5B6212EAAF for ; Tue, 16 Jan 2018 11:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 IOEK50gjMzqw for ; Tue, 16 Jan 2018 11:14:49 -0800 (PST) Received: from purin.rz.uni-konstanz.de (purin.rz.uni-konstanz.de [134.34.240.45]) (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 A5B6612EAB1 for ; Tue, 16 Jan 2018 11:14:47 -0800 (PST) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by viribus.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 19:14:44 +0000 Received: from [192.168.1.12] (HSI-KBW-5-158-128-23.hsi19.kabel-badenwuerttemberg.de [5.158.128.23]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id D92FC134 for ; Tue, 16 Jan 2018 20:14:44 +0100 (CET) To: "dnssd@ietf.org" From: Daniel Kaiser Message-ID: <402004c8-0aaa-6d88-4645-622edf34424b@uni-konstanz.de> Date: Tue, 16 Jan 2018 20:14:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F2DE55FF6AA6EA625FA40F61" Content-Language: en-GB-large Archived-At: Subject: [dnssd] Pairing Issue: Users might press OK, without actually looking at the SAS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 19:14:52 -0000 This is a multi-part message in MIME format. --------------F2DE55FF6AA6EA625FA40F61 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit [pairing issue 1](https://github.com/huitema/pairing/issues/1) TL;DR --- * this is just a UI issue that does not require changes in the protocol * we could change the "cheatable" compare & confirm UI to a copy & enter UI * our SAS based solution is better suited as it is not dependent on pre-existing passwords   (PAKE achieves authenticity using a pre-existing password, while manual authentication achieves authenticity by a "personal meeting") Longer Version: --- The SAS pairing method we describe in our draft is subdivided into three phases: * discovery * pairing data exchange * manual authentication Only the manual authentication phase influences the UI; it is independent of the other two phases. The manual authentication again can be subdivided into SAS representation --- e.g. representing the SAS as alphanumeric string, as a QR code, or as something more exotic --- and the SAS verification method. In our draft, we describe the compare & confirm verification method on a alphanumeric SAS representation. The compare & confirm method is indeed "cheatable" by the users of the pairing devices but has proven to be the most comfortable one. We can, however, use a copy & enter verification method, which demands the users to read the SAS representation from one device and enter it into the second device. This would result in the same UI that a J-PAKE based protocol would use. ## Comparison Both methods, ours and J-PAKE, offer secure device pairing. Both do not depend on a short PIN that is instrumental in the key generation. Among the advantages over the respective other protocol family are (I might add more later...): ### Manual SAS Authentication Methods * do not need any pre-existing (fixed) passwords * allow for various verification methods (among them the most convenient methods: compare & confirm and QR codes) ### PAKE Methods * do not require an out-of-band channel that grants authenticity (e.g. the devices "meeting in person") ## Discussion >From a UI point of view, both methods can offer the copy & enter method. We do not need to switch to PAKE for offering this. However, only the SAS method offers the more convenient methods, among them QR codes (unless the App manages the PAKE passwords). Further, as a pairing method in the DNS-SD/mDNS area, manual SAS authentication methods are better suited because they are not dependent on a pre-existing password. Using J-PAKE for the pairing of two smart phones, the users of these two devices need a pre-existing password. This poses a new question: How do these users agree on a password. The sociallist millionaires protocol could be used to this end, but it is less convenient for users than verifying an SAS. While PAKE achieves authenticity using a pre-existing password, Manual Authentication achieves authenticity by a "personal meeting". For the DNS-SD/mDNS area, where devices are assumed be be relatively close to each other, the "personal meeting" poses way less overhad than the need for pre-existing passwords. ## Additional: Fixed PIN Devices that do not feature a display and come with a fixed PIN allow only for a lower level of privacy because each device pairing with that device uses the same PIN. We should treat the case of a fixed PIN separately. Regarding (fixed) PIN based protocols, it is important that the PIN is not instrumental in the key generation and just serves authentication purposes. PAKE protocols fulfill that, but they do not offer an authenticated PIN exchange; the PIN (password) is expected to already be known to the pairing parties. ## Questions * Should we stick to our Manual SAS Authentication method? (I am in favor of sticking to it for the afore stated reasons.) * If yes, should we specify the verification method in the draft? * If yes, should we specify both compare & confirm and copy & enter (both could co-exist)? * If not, which one should we choose? * Should we specify the use of fixed PINs in this pairing draft? --------------F2DE55FF6AA6EA625FA40F61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit [pairing issue 1](https://github.com/huitema/pairing/issues/1)

TL;DR
---

* this is just a UI issue that does not require changes in the protocol
* we could change the "cheatable" compare & confirm UI to a copy & enter UI
* our SAS based solution is better suited as it is not dependent on pre-existing passwords
  (PAKE achieves authenticity using a pre-existing password, while manual authentication achieves authenticity by a "personal meeting")


Longer Version:
---

The SAS pairing method we describe in our draft is subdivided into three phases:

* discovery
* pairing data exchange
* manual authentication

Only the manual authentication phase influences the UI; it is independent of the other two phases.
The manual authentication again can be subdivided into SAS representation --- e.g. representing the
SAS as alphanumeric string, as a QR code, or as something more exotic ---
and the SAS verification method.
In our draft, we describe the compare & confirm verification method on a alphanumeric SAS representation.
The compare & confirm method is indeed "cheatable" by the users of the pairing devices but has proven to be the most comfortable one.
We can, however, use a copy & enter verification method, which demands the users to read the SAS representation from one device
and enter it into the second device. This would result in the same UI that a J-PAKE based protocol would use.

## Comparison

Both methods, ours and J-PAKE, offer secure device pairing.
Both do not depend on a short PIN that is instrumental in the key generation.

Among the advantages over the respective other protocol family are (I might add more later...):

### Manual SAS Authentication Methods

* do not need any pre-existing (fixed) passwords
* allow for various verification methods (among them the most convenient methods: compare & confirm and QR codes)

### PAKE Methods

* do not require an out-of-band channel that grants authenticity (e.g. the devices "meeting in person")


## Discussion

From a UI point of view, both methods can offer the copy & enter method.
We do not need to switch to PAKE for offering this.
However, only the SAS method offers the more convenient methods, among them QR codes (unless the App manages the PAKE passwords).


Further, as a pairing method in the DNS-SD/mDNS area, manual SAS authentication methods are better suited because they are not dependent on
a pre-existing password.
Using J-PAKE for the pairing of two smart phones, the users of these two devices need a pre-existing password.
This poses a new question: How do these users agree on a password.
The sociallist millionaires protocol could be used to this end, but it is less convenient for users than verifying an SAS.

While PAKE achieves authenticity using a pre-existing password, Manual Authentication achieves authenticity by a "personal meeting".
For the DNS-SD/mDNS area, where devices are assumed be be relatively close to each other, the "personal meeting" poses way less
overhad than the need for pre-existing passwords.


## Additional: Fixed PIN

Devices that do not feature a display and come with a fixed PIN allow only for a lower level of privacy because each
device pairing with that device uses the same PIN.
We should treat the case of a fixed PIN separately.

Regarding (fixed) PIN based protocols, it is important that the PIN is not instrumental in the key generation and just serves authentication purposes.
PAKE protocols fulfill that, but they do not offer an authenticated PIN exchange; the PIN (password) is expected to already be known to the pairing parties.

## Questions

* Should we stick to our Manual SAS Authentication method? (I am in favor of sticking to it for the afore stated reasons.)
* If yes, should we specify the verification method in the draft?
* If yes, should we specify both compare & confirm and copy & enter (both could co-exist)?
* If not, which one should we choose?
* Should we specify the use of fixed PINs in this pairing draft?

 --------------F2DE55FF6AA6EA625FA40F61--