From nobody Fri Feb 8 04:43:19 2019 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 875AE1288BD; Fri, 8 Feb 2019 04:43:16 -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, bs7652@att.com, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154962979651.15934.9693641478798544453.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2019 04:43:16 -0800 Archived-At: Subject: [dnssd] dnssd - Update to a Meeting Session Request for IETF 104 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 08 Feb 2019 12:43:16 -0000 An update to a meeting session request has just been submitted by Barbara Stark, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Barbara Stark Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: 6man dnsop doh dprive homenet quic mls core anima babel Second Priority: ipsecme intarea v6ops People who must be present: Eric Vyncke Terry Manderson Barbara Stark David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 8 14:49:48 2019 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 1035B130FC2 for ; Fri, 8 Feb 2019 14:49:46 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 TKdTJJorY6mi for ; Fri, 8 Feb 2019 14:49:44 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 46A6F131052 for ; Fri, 8 Feb 2019 14:49:44 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x18Ml4YM059641; Fri, 8 Feb 2019 14:49:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : message-id : date : cc : to; s=20180706; bh=V6BPL9dk4F/WvFizeC+U5MEOudZ/dbWZI6eqdZGwMqM=; b=m79QlPrDOLsOq4dJez+hGSMQpTVWHI5GbOVGHaMLlafxjLdJDFpfgj0WycHGa+jRNpJk iUKM4P8a2fAIqaFIe/Dfoe/WsVZd1QLW5xx6hU4ZLHl2Z7Zj+vFSBter9RySbGpFdR2h 80ERjX24xbuXbqWnetcpqzQuOwNA1knkKty3cNV/Vj2kmmhSuN8YbGam/w93nieFUJIe zos+jIk8AAnAvQtUYvnAsaKbduCo6tW6kDLxDU68sDstlq4wMWhyIwyg27BctldUG8NQ VEV6DzETposzUSjiJBzvJVIMC9m4l1moM7utbjW1N13G6EK3YHjrsgm5US6EvhMY0z85 +A== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2qdardeqma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 08 Feb 2019 14:49:42 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_at7IZVKsHL8YQ4abIJoZVA)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PMM00GCEQ2SCA90@ma1-mtap-s01.corp.apple.com>; Fri, 08 Feb 2019 14:49:42 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PMM00700PWDY300@nwk-mmpp-sz09.apple.com>; Fri, 08 Feb 2019 14:49:40 -0800 (PST) X-Va-A: X-Va-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-Va-E-CD: 2d572c3b6e9a79f7c50e8a6905f5a5f6 X-Va-R-CD: a111ab216e424768f4db66e5b401a770 X-Va-CD: 0 X-Va-ID: e7fcf0a5-7d80-4466-a03c-7c13f9a77118 X-V-A: X-V-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-V-E-CD: 2d572c3b6e9a79f7c50e8a6905f5a5f6 X-V-R-CD: a111ab216e424768f4db66e5b401a770 X-V-CD: 0 X-V-ID: da638d06-b293-48ff-af94-ec905e29f07e Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PMM00G00Q2P0H00@nwk-mmpp-sz09.apple.com>; Fri, 08 Feb 2019 14:49:39 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-08_12:,, signatures=0 Received: from [17.230.132.170] (unknown [17.230.132.170]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PMM00NQ6Q2R4D30@nwk-mmpp-sz09.apple.com>; Fri, 08 Feb 2019 14:49:39 -0800 (PST) Sender: youenn@apple.com From: youenn fablet Message-id: Date: Fri, 08 Feb 2019 14:49:38 -0800 Cc: Justin Uberti , Jeroen de Borst , Qingsi Wang , Sean Turner , Adam Roach To: dnssd@ietf.org X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-08_12:, , signatures=0 Archived-At: Subject: [dnssd] Feedback on https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 22:49:46 -0000 --Boundary_(ID_at7IZVKsHL8YQ4abIJoZVA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi all, https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02 is describing work being conducted in RTCWeb. Ongoing work on this draft happens in https://github.com/rtcweb-wg/mdns-ice-candidates . The draft defines a way of using ephemeral MDNS names inside ICE candidates instead of raw IP addresses. The motivation is to mitigate fingerprinting happening today on the web. This approach is under experimentation by Chrome and Safari teams. Any feedback on the draft is very welcome. --Boundary_(ID_at7IZVKsHL8YQ4abIJoZVA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = all,

https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidat= es-02 is describing work being conducted in RTCWeb.
Ongoing work on this draft happens in https://github.com/rtcweb-wg/mdns-ice-candidates.

The draft defines = a way of using ephemeral MDNS names inside ICE candidates instead of raw = IP addresses.
The motivation is to mitigate = fingerprinting happening today on the web.
This approach is under experimentation by Chrome and Safari = teams.

Any feedback on the draft is very = welcome.
= --Boundary_(ID_at7IZVKsHL8YQ4abIJoZVA)-- From nobody Tue Feb 12 16:28:35 2019 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 EC8FD1279E6 for ; Tue, 12 Feb 2019 16:28:33 -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, HTML_MESSAGE=0.001, 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 xVuoNSjPCJ5n for ; Tue, 12 Feb 2019 16:28:31 -0800 (PST) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F73126C01 for ; Tue, 12 Feb 2019 16:28:31 -0800 (PST) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id F315927584 for ; Tue, 12 Feb 2019 19:28:30 -0500 (EST) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_7D10C212-CB5A-4B0D-9C02-C921BCE0AFF1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <01AEFE47-E47A-452E-8E93-1AFB836C037A@bangj.com> References: <155001683826.8679.9088527841974603403.idtracker@ietfa.amsl.com> To: dnssd Date: Tue, 12 Feb 2019 19:28:30 -0500 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-pusateri-dnssd-update-proxy-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 00:28:34 -0000 --Apple-Mail=_7D10C212-CB5A-4B0D-9C02-C921BCE0AFF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This new draft describes the DNS Update Proxy, a concept that I came up = with and described briefly in my charter discussion in Montr=C3=A9al. It provides the same functionality as the combination of the Discovery = Proxy and the mDNS Relay but uses DNS Update instead of defining any new = protocols. I plan to discuss this in Prague if agenda time is available. I would love to get some feedback on this even before Prague so that I = may release another version before presenting. I have begun an implementation in the Rust language and will be working = on it during the Hackathon if anyone is interested in joining me. The code has an MIT license and is available on Github: = https://github.com/pusateri/rupdateproxy = The code currently listens = for mDNS announcements and updates a cache and I am currently working on = sending the DNS Updates to an authoritative server. Enjoy, Tom > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-pusateri-dnssd-update-proxy-00.txt > Date: February 12, 2019 at 7:13:58 PM EST > To: "Tom Pusateri" >=20 >=20 > A new version of I-D, draft-pusateri-dnssd-update-proxy-00.txt > has been successfully submitted by Tom Pusateri and posted to the > IETF repository. >=20 > Name: draft-pusateri-dnssd-update-proxy > Revision: 00 > Title: DNS Update Proxy for mDNS > Document date: 2019-02-12 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dnssd-update-proxy-00.= txt > Status: = https://datatracker.ietf.org/doc/draft-pusateri-dnssd-update-proxy/ > Htmlized: = https://tools.ietf.org/html/draft-pusateri-dnssd-update-proxy-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dnssd-update-proxy >=20 >=20 > Abstract: > This document describes a method to dynamically map multicast DNS > announcements into the unicast DNS namespace for use by service > discovery clients. It does not define any new protocols but uses > existing DNS protocols in new ways. This solves existing problems > with service discovery across multiple IP subnets in a simple, yet > efficient, manner. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_7D10C212-CB5A-4B0D-9C02-C921BCE0AFF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = new draft describes the DNS Update Proxy, a concept that I came up with = and described briefly in my charter discussion in Montr=C3=A9al.

It provides the same = functionality as the combination of the Discovery Proxy and the mDNS = Relay but uses DNS Update instead of defining any new = protocols.

I = plan to discuss this in Prague if agenda time is available.

I would love to get some = feedback on this even before Prague so that I may release another = version before presenting.

I have begun an implementation in the Rust language and will = be working on it during the Hackathon if anyone is interested in joining = me.

The code = has an MIT license and is available on Github: https://github.com/pusateri/rupdateproxy  The code = currently listens for mDNS announcements and updates a cache and I am = currently working on sending the DNS Updates to an authoritative = server.

Enjoy,
Tom


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pusateri-dnssd-update-proxy-00.txt
Date: = February 12, 2019 at 7:13:58 PM = EST
To: = "Tom Pusateri" <pusateri@bangj.com>


A new version = of I-D, draft-pusateri-dnssd-update-proxy-00.txt
has been = successfully submitted by Tom Pusateri and posted to the
IETF repository.

Name: = draft-pusateri-dnssd-update-proxy
Revision: 00
Title:= = DNS Update Proxy for mDNS
Document date: = 2019-02-12
Group: Individual Submission
Pages:= = 16
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dnssd-updat= e-proxy-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pusateri-dnssd-update-pr= oxy/
Htmlized:       https://tools.ietf.org/html/draft-pusateri-dnssd-update-proxy-0= 0
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnssd-upda= te-proxy


Abstract:
  This document describes a method to dynamically = map multicast DNS
  announcements into the = unicast DNS namespace for use by service
=   discovery clients.  It does not define any new = protocols but uses
  existing DNS protocols in = new ways.  This solves existing problems
=   with service discovery across multiple IP subnets in a = simple, yet
  efficient, manner.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_7D10C212-CB5A-4B0D-9C02-C921BCE0AFF1-- From nobody Sun Feb 17 12:13:45 2019 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 DB11B126C7E; Sun, 17 Feb 2019 12:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fM_W5KqrFUrD; Sun, 17 Feb 2019 12:13:41 -0800 (PST) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDFB128CB7; Sun, 17 Feb 2019 12:13:37 -0800 (PST) Received: from [172.16.10.110] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 896A627C3B; Sun, 17 Feb 2019 15:13:36 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Sun, 17 Feb 2019 15:13:35 -0500 Cc: dnssd To: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 20:13:43 -0000 While this document is an RTCWEB document, it=E2=80=99s more about mDNS = and so I=E2=80=99m going to give feedback directly to the authors and = the DNS-SD group instead of the RTCWEB group (which I=E2=80=99m not a = member). If the authors want to replicate this discussion on RTCWEB, = please do so. Overall, it=E2=80=99s an interesting idea and I think it could work ok. = However, I think presentation around ICE, while motivating the idea, is = not necessary for a general purpose third party mDNS name aliasing = mechanism. I would remove all references to ICE, WebRTC, TURN, etc. and = just make a simple mDNS third party name alias registration document. As part of that, you need to discuss defending the name and responding = to queries for the name since the owner of the IP address will not do = this. Section 3.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D List Item 1: Someone familiar with mDNS would interpret this as an existing = registered mDNS host name. I don=E2=80=99t think that=E2=80=99s what = this means. I think this means an existing RFC 4122 unique name as = described further down in the document. List Item 3: This makes it seem like normal mDNS is occurring here when it=E2=80=99s = really a 3rd party form of mDNS. So you=E2=80=99re not really following = RFC 6762. I don=E2=80=99t think there=E2=80=99s necessarily a problem = with 3rd party registrations but don=E2=80=99t point people to RFC 6762 = for that. In fact, you=E2=80=99re extending RFC 6762 and you need to = describe in more detail how you=E2=80=99re extending it. 3rd last paragraph: "with both IPv4 and IPv6 addresses MUST expose a different mDNS name for = each address." Again, you=E2=80=99re talking about RFC 4122 unique names, not regular = mDNS names as provided by a host. This should be made more clear since = it would be common for an mDNS host to use the same name for IPv4 and = IPv6. Section 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd paragraph: When more than one IPv4 or more than one IPv6 address is present, it = seems like it would be better to first prefer an address that is on a = shared network instead of always taking the first one (which doesn=E2=80=99= t mean anything in DNS). If you want others to use the same address you = should prefer the lowest one or the highest one or something sortable = instead of the first one which could be different depending on hashing = in a cache. Thanks, Tom From nobody Sun Feb 17 14:30:09 2019 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 42F6E126F72; Sun, 17 Feb 2019 14:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mgicdoE2_lOA; Sun, 17 Feb 2019 14:30:05 -0800 (PST) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BBA124D68; Sun, 17 Feb 2019 14:30:04 -0800 (PST) Received: from [172.16.10.124] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EAFDB27C52; Sun, 17 Feb 2019 17:30:03 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Sun, 17 Feb 2019 17:30:03 -0500 Cc: dnssd Content-Transfer-Encoding: quoted-printable Message-Id: <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com> References: To: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org Archived-At: Subject: Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 22:30:07 -0000 > On Feb 17, 2019, at 3:13 PM, Tom Pusateri wrote: >=20 > While this document is an RTCWEB document, it=E2=80=99s more about mDNS an= d so I=E2=80=99m going to give feedback directly to the authors and the DNS-= SD group instead of the RTCWEB group (which I=E2=80=99m not a member). If th= e authors want to replicate this discussion on RTCWEB, please do so. >=20 >=20 > Overall, it=E2=80=99s an interesting idea and I think it could work ok. Ho= wever, I think presentation around ICE, while motivating the idea, is not ne= cessary for a general purpose third party mDNS name aliasing mechanism. I wo= uld remove all references to ICE, WebRTC, TURN, etc. and just make a simple m= DNS third party name alias registration document. >=20 > As part of that, you need to discuss defending the name and responding to q= ueries for the name since the owner of the IP address will not do this. >=20 > Section 3.1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > List Item 1: >=20 > Someone familiar with mDNS would interpret this as an existing registered m= DNS host name. I don=E2=80=99t think that=E2=80=99s what this means. I think= this means an existing RFC 4122 unique name as described further down in th= e document. >=20 > List Item 3: >=20 > This makes it seem like normal mDNS is occurring here when it=E2=80=99s re= ally a 3rd party form of mDNS. So you=E2=80=99re not really following RFC 67= 62. I don=E2=80=99t think there=E2=80=99s necessarily a problem with 3rd par= ty registrations but don=E2=80=99t point people to RFC 6762 for that. In fac= t, you=E2=80=99re extending RFC 6762 and you need to describe in more detail= how you=E2=80=99re extending it. >=20 >=20 > 3rd last paragraph: >=20 > "with both IPv4 and IPv6 addresses MUST expose a different mDNS name for e= ach address." >=20 > Again, you=E2=80=99re talking about RFC 4122 unique names, not regular mDN= S names as provided by a host. This should be made more clear since it would= be common for an mDNS host to use the same name for IPv4 and IPv6. >=20 >=20 > Section 4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 2nd paragraph: >=20 > When more than one IPv4 or more than one IPv6 address is present, it seems= like it would be better to first prefer an address that is on a shared netw= ork instead of always taking the first one (which doesn=E2=80=99t mean anyth= ing in DNS). If you want others to use the same address you should prefer th= e lowest one or the highest one or something sortable instead of the first o= ne which could be different depending on hashing in a cache. >=20 > Thanks, > Tom Thinking about this a little more, I would suggest splitting this into two d= ocuments. One that describes an mDNS alias name registration extension to RFC= 6 762 and a second document that uses the first document to create unique R= FC 4122 names for rtcweb. Tom= From nobody Mon Feb 18 05:04:46 2019 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 D1A9B127AC2; Mon, 18 Feb 2019 05:04:44 -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, HTML_MESSAGE=0.001, 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 33MxilIKOQCe; Mon, 18 Feb 2019 05:04:42 -0800 (PST) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EC71277CC; Mon, 18 Feb 2019 05:04:42 -0800 (PST) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 755B227CEF; Mon, 18 Feb 2019 08:04:41 -0500 (EST) From: Tom Pusateri Message-Id: <27B3FC67-EE91-4D6D-B8AE-17A79348D147@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_93CF4D7A-90D8-4E78-A6BA-4F0A81CD5447" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 18 Feb 2019 08:04:40 -0500 In-Reply-To: <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com> Cc: dnssd To: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org References: <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 13:04:45 -0000 --Apple-Mail=_93CF4D7A-90D8-4E78-A6BA-4F0A81CD5447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 17, 2019, at 5:30 PM, Tom Pusateri wrote: >=20 > Thinking about this a little more, I would suggest splitting this into = two documents. One that describes an mDNS alias name registration = extension to RFC 6 762 and a second document that uses the first = document to create unique RFC 4122 names for rtcweb. >=20 As I=E2=80=99ve thought about this overnight, I=E2=80=99m not convinced = that extending mDNS for name aliases is even necessary. If you did, I = would definitely want to know the response is not from the owner which = means defining a new header bit or new OPT extension. A simpler way to achieve this would be to just define a new service = provided by the name mapper. The mapper can generate unique names for IP = addresses as needed and limit their time and scope as it sees fit. When another process needs to know if a unique .local name resolves to a = local IP address, it can locate the name mapper using service discovery = (PTR query for _ice-name-mapper._tcp.local, etc.), get the SRV record = and ask the target directly. Tom --Apple-Mail=_93CF4D7A-90D8-4E78-A6BA-4F0A81CD5447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 17, 2019, at 5:30 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

Thinking about this a little more, I would suggest splitting = this into two documents. One that describes an mDNS alias name = registration extension to RFC 6 762 and a second document that uses the = first document to create unique RFC 4122 names for rtcweb.


As I=E2=80=99ve thought about this overnight, = I=E2=80=99m not convinced that extending mDNS for name aliases is even = necessary. If you did, I would definitely want to know the response is = not from the owner which means defining a new header bit or new OPT = extension.

A simpler way to achieve = this would be to just define a new service provided by the name mapper. = The mapper can generate unique names for IP addresses as needed and = limit their time and scope as it sees fit.

When another process needs to know if a unique = .local name resolves to a local IP address, it can locate the name = mapper using service discovery (PTR query for = _ice-name-mapper._tcp.local, etc.), get the SRV record and ask the = target directly.

Tom


= --Apple-Mail=_93CF4D7A-90D8-4E78-A6BA-4F0A81CD5447-- From nobody Sun Feb 24 07:43:36 2019 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 6A48F127AC2 for ; Sun, 24 Feb 2019 07:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8m54RC3Zdp4q for ; Sun, 24 Feb 2019 07:43:32 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 81B5B124B0C for ; Sun, 24 Feb 2019 07:43:32 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1OFYxEN039657 for ; Sun, 24 Feb 2019 10:43:32 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2quqgypvpx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 24 Feb 2019 10:43:31 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1OFhUWH004422 for ; Sun, 24 Feb 2019 10:43:30 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1OFhRsX004404 for ; Sun, 24 Feb 2019 10:43:28 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 57F954014052 for ; Sun, 24 Feb 2019 15:43:27 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30487.vci.att.com (Service) with ESMTPS id 43C674014040 for ; Sun, 24 Feb 2019 15:43:27 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0435.000; Sun, 24 Feb 2019 10:43:26 -0500 From: "STARK, BARBARA H" To: "dnssd@ietf.org" Thread-Topic: IETF 104 agenda Thread-Index: AdTMVtki+uj86NJDSfaYfPPMsu4xvA== Date: Sun, 24 Feb 2019 15:43:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E0B8670@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.206.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=380 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902240123 Archived-At: Subject: [dnssd] IETF 104 agenda 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 15:43:35 -0000 Hi dnssd, The IESG has published the preliminary IETF 104 agenda. dnssd is currently = scheduled for 16:10-18:10 Monday Afternoon session II. Other sessions at th= at time are httpbis, smart, qirg, idr, roll, oauth, and tsvwg. https://datatracker.ietf.org/meeting/104/agenda.html=20 If any key dnssd people think they will have issues with this time slot, pl= ease let your friendly and helpful dnssd chairs know. FYI, I'm seeing more claims of scheduling conflicts (lots of inter-chair ch= atter) with this schedule than I've seen in the past. It seems there are mo= re scheduling conflicts because Wednesday afternoon has no sessions. Wednes= day afternoon is being left open for people to schedule ad hoc meetings.=20 Barbara From nobody Mon Feb 25 19:55:58 2019 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 9ED64130E6A for ; Mon, 25 Feb 2019 19:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 L73R5QQyBQUo for ; Mon, 25 Feb 2019 19:55:52 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 F01741295EC for ; Mon, 25 Feb 2019 19:55:49 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id i204so2088604ywb.0 for ; Mon, 25 Feb 2019 19:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2Jriw6HV7/o6J9RQmUEwEGsb3UO7pDzRL/8YeCftXkk=; b=JI//sBqCSPu+VHfN3al8ceoeMuhIyXyaGcXvRE4VhevyyjfTgi8S14Qh4sT/9dH5/P 52cCxTadRAuF1iV0dP0Iw06C43QSv7iAoNk8/q8JziP4oDJ1dnhzLV8cKt1ErkwW0NZa ppHassN+hrpTXejbRjfAT2WFMUalny8slvI8FPkuL7jGdccNRFHNBb5J1sWAfznypUIy h+tYOKyPy4qF0dYUTWKbVYEB2LLgt9z+Qw1c0uU5tTmj5FAUiLyhW/G6seDMpgXGNohy 86Rr9Ub2fosnozdiR6ksVljNBDkFSPgJaBEvpucG7uBPgOMPiV/k5kqIYo8967gBpCog rHzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2Jriw6HV7/o6J9RQmUEwEGsb3UO7pDzRL/8YeCftXkk=; b=jvT3RjmmsH+/Na5Jn4wMdaMvwoB3kmNLy0ah3qCWVoZfbTvIpSmzruiuO1Z4gg+I7N 8oRZkm51oXbx73cDo70X2v43NAjE8oab7vORGjUzTCrjc/CvpH7G27qQiO5DAxLY7NwM pH9D5FpJy4xpBPIT+mv9DlKmVX+eOQlF7Wurx8qJMBPYyzp7tlkFLYgb74HO++YKofb5 TQyRDEF+W/Ex1IEu12sPqgYyaM8XNVT9yMqJQxUBu0MTL/wCgm+rlp66mVtwmp25dCGV XMXBopkMFbDBINoxoIKFFQllhHyTpQsxrtkSFtKxeMh1WNQ7C/zLi52c0m5/wqxQkX4n CPkw== X-Gm-Message-State: AHQUAuYufrLQi+g+1twoVrSt676Iztet2V3KcMeyHC/Y6noXcZBW4u8t hAFDFvHGy326XvnL4t/Rk4n4qGzKMFCyyMPMSaQ= X-Google-Smtp-Source: AHgI3Iaj/8mEiVTYqh5qbjvwhiGcGWJtcJ1vGb8YNO64ZRvjJr28jPnuFljv9hy7sT5WTtsv3EiDH5Nhd7TKSaEX6jg= X-Received: by 2002:a81:2544:: with SMTP id l65mr16663909ywl.263.1551153348730; Mon, 25 Feb 2019 19:55:48 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> In-Reply-To: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> From: Christopher Wood Date: Mon, 25 Feb 2019 19:55:37 -0800 Message-ID: To: Bob Bradley Cc: DNSSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 03:55:57 -0000 (Paging back in discussions from the meeting...) On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley wrote: > > I'm a little unclear what is being considered single-stage vs two-stage. = How is single-stage able to send encrypted without knowing the destination?= Is it encrypting a query with an asymmetric private key and multicasting? = Or does single-stage refer to the predictable nonce approach? I was conside= ring predictable nonce's two-stage because it has to first discover known p= eer service instances (stage 1) then perform encrypted queries/responses (s= tage 2). If I understand and remember correctly, the single stage approach would encrypt the service ID in the first query using the recipient's public key, along with the predictable nonce generated using the sender's public key. The response would contain the address of the service in question. If we are concerned with the dictionary attack mentioned earlier, a second round is required. I assume the joint design with you, Christian, and Daniel will attempt to find an appropriate balance here. Best, Chris > Regarding the discussion: > > 1. Server mode. My proposal doesn't have a good way to support it. Normal= server mode wasn't an important use case for me, but sleep proxy support w= ould be nice. I just don't know how to do it yet, at least not without givi= ng the sleep proxy your keys. > > 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is = each device advertising a service instance for each pairing. The network I'= m on now has 300+ devices and if each one has 50 friends, that's 15000 serv= ice instances on the network, which seems very high. > > I tried to reduce this by each device only advertising itself via multica= st and then everything else is unicast. The first part of key exchange was = also rolled into the advertisement packet to allow a single query packet an= d single response packet while still maintaining forward secrecy and per-pa= iring confidentiality. > > 3. CPU cost. This seems to be a comparison between more packets, but lowe= r per-packet cost (in the per-pairing service instance model where predicta= ble nonce hashes are precomputed) vs fewer packets, but more expensive per-= packet signature verification. The two main use cases I was considering wer= e home networks (where neither traffic nor CPU is likely to be an issue due= to the small number of devices) and busy enterprise networks (office, dorm= , coffee shop), which I assumed would be more powerful devices (laptops, ph= ones, servers) where reducing traffic would be more important than the CPU = usage for checking multicast probes. > > 4. One privacy concern regarding predictable nonces is that it would allo= w spoofing. Anyone with your public key could generate your predictable non= ce. It could also enable friend relationships to be recovered. Maybe not a = huge concern, but something to consider. Even the signature approach has a = replay vulnerability, but it's time bounded. > > On Nov 14, 2018, at 5:37 PM, David Schinazi wr= ote: > > Hello everyone, > > It the room at IETF 103, there was a very productive discussion about DNS= SD privacy: > https://www.youtube.com/watch?v=3DhPuTD19R-uQ&t=3D28m43s > > During that discussion, the room reached consensus on the following items= : > > 1) single-stage approach -- Up until now, we were considering two approac= hes: single-stage (send encrypted and authenticated service identifier, rec= eive encrypted and authenticated service response) and two-stage (send encr= yption and authenticated identifier, receive encrypted and authenticated re= sponse, derive secrets, send and receive subsequent queries encrypted using= derived secrets). There was consensus in the room to go with the single-st= age approach. > > 2) Use of TLS -- The single-stage approach no longer requires a key excha= nge mechanism such as TLS. There was consensus in the room that we do not n= eed TLS as part of this protocol. > > 3) Evolution of documents -- It was proposed that we would take all input= and compound it into a single document and only advance that one. We will = use draft-ietf-dnssd-privacy since that document has already been adopted b= y the working group. Christian Huitema has offered for Bob Bradley to join = as co-author if Bob would like. > > If you disagree with any of these points, please say so before 2018-12-02= . > > Thanks, > David > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Feb 26 09:36:02 2019 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 51412130ECD for ; Tue, 26 Feb 2019 09:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 QC5xLhMnhEUC for ; Tue, 26 Feb 2019 09:35:37 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 F1C96130E5D for ; Tue, 26 Feb 2019 09:35:36 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id p19so6576388plo.2 for ; Tue, 26 Feb 2019 09:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dCJKC0jmUOyXSLmRVNrHcL3t1QGNyTK4w2bPz97gZkc=; b=ZLJWDzTY/V2NEQAZEWi0ufv+VosZcU9XL/814uZnmHIre3yuYZsUFrQ9+wG3/6bjLz FkKj0/i8wQ6VjGMSpL7/uxSIJ/nN6R56Mw+jQ9zy7ffm8cE9J2BdiFz0oZ2SAuuvsUM3 g4nyrGC/fYUh0JKuU9e+3NecTK6ajjixf5919F8MdPMBkkzbvlEeYmPCVlfO83C5hHtu i3lOqaSzDT4zE4KRdx3EVQK59S08wycPR70MGLJHY1/K+K2vyZRc8p7DOBBIBsszwoug 21ERsfQYyDOa5wnGz93lvPnnnbHDTW9mbrttucBw+mLj9EshFNlO0gNnJV4S6EaLEKeP 0/NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dCJKC0jmUOyXSLmRVNrHcL3t1QGNyTK4w2bPz97gZkc=; b=fR1CCpSarlF16mGjbUqqJLYquMe6HVPDOCT+vk3jIsPDKuWSLQ8F8I7cuhhJjkXf8O lbMM+0XpXRnpRa8vDiA5dxskp5BGn61VytMRFlI57CjBeMX4OCvgFGJuIab6ULb3tkgI +fKjzpCJhPxJbGdLLBw+cHI7lrm/4xpuV3TngdDG6msvupascDTUTV7JTCk/jnToju4C Robqv8HqKShTdKx51DFGpXROfGMbPgBg83bwtzWiqukI6kiQyttiA95EZ3YsAYbrJRpR dl//pndW+WSB+kjZsgkip90lWLlJgyqwjb9AJWu2qCI9l534EqzJ0GJgRWw5A7eU+Cuy YJYg== X-Gm-Message-State: AHQUAuYdrue6de53n+ms0DzBx6eP9z4276kavrBCqbIQzjhhJiDrg2i2 Lp8t5yCaNZMT6BNtWzUA8Hr+nYJJo+WvKbGL9rc= X-Google-Smtp-Source: AHgI3IbRxcNwB5yTNoFHDbBlM0r7O9lDyLm9XHi6JyquGC9oHxFSybrhaSgSCpIjWB5MSRtfhLvb2jWy3jEnUuHGWtI= X-Received: by 2002:a17:902:7207:: with SMTP id ba7mr26589311plb.16.1551202536287; Tue, 26 Feb 2019 09:35:36 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> In-Reply-To: From: David Schinazi Date: Tue, 26 Feb 2019 09:35:25 -0800 Message-ID: To: Christopher Wood , Christian Huitema , Bob Bradley Cc: DNSSD Content-Type: multipart/alternative; boundary="0000000000002673110582cf7c1f" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 17:35:46 -0000 --0000000000002673110582cf7c1f Content-Type: text/plain; charset="UTF-8" Thanks for kicking this discussion off again, Chris! Bob, Christian, is there anything the chairs can do to facilitate making progress towards a joint proposal before Prague? Thanks, David On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood < christopherwood07@gmail.com> wrote: > (Paging back in discussions from the meeting...) > > On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley wrote: > > > > I'm a little unclear what is being considered single-stage vs two-stage. > How is single-stage able to send encrypted without knowing the destination? > Is it encrypting a query with an asymmetric private key and multicasting? > Or does single-stage refer to the predictable nonce approach? I was > considering predictable nonce's two-stage because it has to first discover > known peer service instances (stage 1) then perform encrypted > queries/responses (stage 2). > > If I understand and remember correctly, the single stage approach > would encrypt the service ID in the first query using the recipient's > public key, along with the predictable nonce generated using the > sender's public key. The response would contain the address of the > service in question. If we are concerned with the dictionary attack > mentioned earlier, a second round is required. > > I assume the joint design with you, Christian, and Daniel will attempt > to find an appropriate balance here. > > Best, > Chris > > > Regarding the discussion: > > > > 1. Server mode. My proposal doesn't have a good way to support it. > Normal server mode wasn't an important use case for me, but sleep proxy > support would be nice. I just don't know how to do it yet, at least not > without giving the sleep proxy your keys. > > > > 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is > each device advertising a service instance for each pairing. The network > I'm on now has 300+ devices and if each one has 50 friends, that's 15000 > service instances on the network, which seems very high. > > > > I tried to reduce this by each device only advertising itself via > multicast and then everything else is unicast. The first part of key > exchange was also rolled into the advertisement packet to allow a single > query packet and single response packet while still maintaining forward > secrecy and per-pairing confidentiality. > > > > 3. CPU cost. This seems to be a comparison between more packets, but > lower per-packet cost (in the per-pairing service instance model where > predictable nonce hashes are precomputed) vs fewer packets, but more > expensive per-packet signature verification. The two main use cases I was > considering were home networks (where neither traffic nor CPU is likely to > be an issue due to the small number of devices) and busy enterprise > networks (office, dorm, coffee shop), which I assumed would be more > powerful devices (laptops, phones, servers) where reducing traffic would be > more important than the CPU usage for checking multicast probes. > > > > 4. One privacy concern regarding predictable nonces is that it would > allow spoofing. Anyone with your public key could generate your predictable > nonce. It could also enable friend relationships to be recovered. Maybe not > a huge concern, but something to consider. Even the signature approach has > a replay vulnerability, but it's time bounded. > > > > On Nov 14, 2018, at 5:37 PM, David Schinazi > wrote: > > > > Hello everyone, > > > > It the room at IETF 103, there was a very productive discussion about > DNSSD privacy: > > https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s > > > > During that discussion, the room reached consensus on the following > items: > > > > 1) single-stage approach -- Up until now, we were considering two > approaches: single-stage (send encrypted and authenticated service > identifier, receive encrypted and authenticated service response) and > two-stage (send encryption and authenticated identifier, receive encrypted > and authenticated response, derive secrets, send and receive subsequent > queries encrypted using derived secrets). There was consensus in the room > to go with the single-stage approach. > > > > 2) Use of TLS -- The single-stage approach no longer requires a key > exchange mechanism such as TLS. There was consensus in the room that we do > not need TLS as part of this protocol. > > > > 3) Evolution of documents -- It was proposed that we would take all > input and compound it into a single document and only advance that one. We > will use draft-ietf-dnssd-privacy since that document has already been > adopted by the working group. Christian Huitema has offered for Bob Bradley > to join as co-author if Bob would like. > > > > If you disagree with any of these points, please say so before > 2018-12-02. > > > > Thanks, > > David > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > > > > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000002673110582cf7c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for kicking this discussion off again, Chris!
<= br>
Bob, Christian, is there anything the chairs can do to facili= tate making progress towards a joint proposal before Prague?

=
Thanks,
David

On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood <christopherwood07@gmail.com= > wrote:
(Pag= ing back in discussions from the meeting...)

On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <bradley@apple.com> wrote:
>
> I'm a little unclear what is being considered single-stage vs two-= stage. How is single-stage able to send encrypted without knowing the desti= nation? Is it encrypting a query with an asymmetric private key and multica= sting? Or does single-stage refer to the predictable nonce approach? I was = considering predictable nonce's two-stage because it has to first disco= ver known peer service instances (stage 1) then perform encrypted queries/r= esponses (stage 2).

If I understand and remember correctly, the single stage approach
would encrypt the service ID in the first query using the recipient's public key, along with the predictable nonce generated using the
sender's public key. The response would contain the address of the
service in question. If we are concerned with the dictionary attack
mentioned earlier, a second round is required.

I assume the joint design with you, Christian, and Daniel will attempt
to find an appropriate balance here.

Best,
Chris

> Regarding the discussion:
>
> 1. Server mode. My proposal doesn't have a good way to support it.= Normal server mode wasn't an important use case for me, but sleep prox= y support would be nice. I just don't know how to do it yet, at least n= ot without giving the sleep proxy your keys.
>
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy = is each device advertising a service instance for each pairing. The network= I'm on now has 300+ devices and if each one has 50 friends, that's= 15000 service instances on the network, which seems very high.
>
> I tried to reduce this by each device only advertising itself via mult= icast and then everything else is unicast. The first part of key exchange w= as also rolled into the advertisement packet to allow a single query packet= and single response packet while still maintaining forward secrecy and per= -pairing confidentiality.
>
> 3. CPU cost. This seems to be a comparison between more packets, but l= ower per-packet cost (in the per-pairing service instance model where predi= ctable nonce hashes are precomputed) vs fewer packets, but more expensive p= er-packet signature verification. The two main use cases I was considering = were home networks (where neither traffic nor CPU is likely to be an issue = due to the small number of devices) and busy enterprise networks (office, d= orm, coffee shop), which I assumed would be more powerful devices (laptops,= phones, servers) where reducing traffic would be more important than the C= PU usage for checking multicast probes.
>
> 4. One privacy concern regarding predictable nonces is that it would a= llow spoofing. Anyone with your public key could generate your predictable = nonce. It could also enable friend relationships to be recovered. Maybe not= a huge concern, but something to consider. Even the signature approach has= a replay vulnerability, but it's time bounded.
>
> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com> wr= ote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about = DNSSD privacy:
> https://www.youtube.com/watch?v=3Dh= PuTD19R-uQ&t=3D28m43s
>
> During that discussion, the room reached consensus on the following it= ems:
>
> 1) single-stage approach -- Up until now, we were considering two appr= oaches: single-stage (send encrypted and authenticated service identifier, = receive encrypted and authenticated service response) and two-stage (send e= ncryption and authenticated identifier, receive encrypted and authenticated= response, derive secrets, send and receive subsequent queries encrypted us= ing derived secrets). There was consensus in the room to go with the single= -stage approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key ex= change mechanism such as TLS. There was consensus in the room that we do no= t need TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all in= put and compound it into a single document and only advance that one. We wi= ll use draft-ietf-dnssd-privacy since that document has already been adopte= d by the working group. Christian Huitema has offered for Bob Bradley to jo= in as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12= -02.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000002673110582cf7c1f-- From nobody Wed Feb 27 10:35:20 2019 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 6A3201310D2 for ; Wed, 27 Feb 2019 10:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, 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 VzbZddbg3DBn for ; Wed, 27 Feb 2019 10:35: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 696151310E4 for ; Wed, 27 Feb 2019 10:35:14 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gz42r-0006Cp-Ee for dnssd@ietf.org; Wed, 27 Feb 2019 19:35:12 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gz42k-0007Ft-Ry for dnssd@ietf.org; Wed, 27 Feb 2019 13:35:02 -0500 Received: (qmail 6418 invoked from network); 27 Feb 2019 18:34:57 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Feb 2019 18:34:57 -0000 To: David Schinazi , Christopher Wood , Bob Bradley Cc: DNSSD References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> From: Christian Huitema 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: Date: Wed, 27 Feb 2019 10:34:47 -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: Content-Type: multipart/alternative; boundary="------------5A58524AA7FB6C22B43F9633" Content-Language: en-US X-Originating-IP: 168.144.250.232 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.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tvyvbqM2+rlZGFYE8Ll8Dt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxflDpvuMKifL0Ot10Fq6b7VDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5+lC8ScYqqrIKKgZkuEMYGaXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseytLy0an6SuH9Dnc48fGLIT5nvmah7oAQX1Q8bvqOef6zFxIBG4U6zc ejwwDTzWEHhqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+elpXlXsYEKiOTsiESb6idaDg5/bq7ChmPMN Ycw1QSmROOi1GrcaCpWZj2qYWnERja9VIPtUUhELGDVKeDd2fFFm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiimxcJ9s1w9uxbJROTdpUdu+NTKQHNkjJg8xvPcdYB8X9H4DectLaqn7kLkt Zo9lq/27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 18:35:18 -0000 This is a multi-part message in MIME format. --------------5A58524AA7FB6C22B43F9633 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think we understand the envelope of the solutions, but we have to stabilize three design choices first: 1) Is the server mode important for the scenarios that we are thinking about? 2) Do we care about compatibility with the existing DNS-SD formats? 3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.) We can easily write a spec that works without server mode, using binary formats, and runs as an app library. That's basically Bob's design, with an optional tweak to add an hint and minimize the CPU cost of trial decryption. We could also tweak the same spec and make it somehow fit in DNS formats, with a liberal usage of TXT records, but I don't know whether that's justified. We do not have a consensus on a server based solution, let alone on a server based solution that would reuse DNS servers.=C2=A0 Basically, the best way for the chairs and the working group to help is to focus the work on a key scenario, and answer the three questions above= =2E -- Christian Huitema On 2/26/2019 9:35 AM, David Schinazi wrote: > Thanks for kicking this discussion off again, Chris! > > Bob, Christian, is there anything the chairs can do to facilitate > making progress towards a joint proposal before Prague? > > Thanks, > David > > On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood > > wrot= e: > > (Paging back in discussions from the meeting...) > > On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley > wrote: > > > > I'm a little unclear what is being considered single-stage vs > two-stage. How is single-stage able to send encrypted without > knowing the destination? Is it encrypting a query with an > asymmetric private key and multicasting? Or does single-stage > refer to the predictable nonce approach? I was considering > predictable nonce's two-stage because it has to first discover > known peer service instances (stage 1) then perform encrypted > queries/responses (stage 2). > > If I understand and remember correctly, the single stage approach > would encrypt the service ID in the first query using the recipient= 's > public key, along with the predictable nonce generated using the > sender's public key. The response would contain the address of the > service in question. If we are concerned with the dictionary attack= > mentioned earlier, a second round is required. > > I assume the joint design with you, Christian, and Daniel will atte= mpt > to find an appropriate balance here. > > Best, > Chris > > > Regarding the discussion: > > > > 1. Server mode. My proposal doesn't have a good way to support > it. Normal server mode wasn't an important use case for me, but > sleep proxy support would be nice. I just don't know how to do it > yet, at least not without giving the sleep proxy your keys. > > > > 2. Multicast traffic. One problem I saw with > draft-ietf-dnssd-privacy is each device advertising a service > instance for each pairing. The network I'm on now has 300+ devices > and if each one has 50 friends, that's 15000 service instances on > the network, which seems very high. > > > > I tried to reduce this by each device only advertising itself > via multicast and then everything else is unicast. The first part > of key exchange was also rolled into the advertisement packet to > allow a single query packet and single response packet while still > maintaining forward secrecy and per-pairing confidentiality. > > > > 3. CPU cost. This seems to be a comparison between more packets, > but lower per-packet cost (in the per-pairing service instance > model where predictable nonce hashes are precomputed) vs fewer > packets, but more expensive per-packet signature verification. The > two main use cases I was considering were home networks (where > neither traffic nor CPU is likely to be an issue due to the small > number of devices) and busy enterprise networks (office, dorm, > coffee shop), which I assumed would be more powerful devices > (laptops, phones, servers) where reducing traffic would be more > important than the CPU usage for checking multicast probes. > > > > 4. One privacy concern regarding predictable nonces is that it > would allow spoofing. Anyone with your public key could generate > your predictable nonce. It could also enable friend relationships > to be recovered. Maybe not a huge concern, but something to > consider. Even the signature approach has a replay vulnerability, > but it's time bounded. > > > > On Nov 14, 2018, at 5:37 PM, David Schinazi > > wrote:= > > > > Hello everyone, > > > > It the room at IETF 103, there was a very productive discussion > about DNSSD privacy: > > https://www.youtube.com/watch?v=3DhPuTD19R-uQ&t=3D28m43s > > > > During that discussion, the room reached consensus on the > following items: > > > > 1) single-stage approach -- Up until now, we were considering > two approaches: single-stage (send encrypted and authenticated > service identifier, receive encrypted and authenticated service > response) and two-stage (send encryption and authenticated > identifier, receive encrypted and authenticated response, derive > secrets, send and receive subsequent queries encrypted using > derived secrets). There was consensus in the room to go with the > single-stage approach. > > > > 2) Use of TLS -- The single-stage approach no longer requires a > key exchange mechanism such as TLS. There was consensus in the > room that we do not need TLS as part of this protocol. > > > > 3) Evolution of documents -- It was proposed that we would take > all input and compound it into a single document and only advance > that one. We will use draft-ietf-dnssd-privacy since that document > has already been adopted by the working group. Christian Huitema > has offered for Bob Bradley to join as co-author if Bob would like.= > > > > If you disagree with any of these points, please say so before > 2018-12-02. > > > > Thanks, > > David > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > > > > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --------------5A58524AA7FB6C22B43F9633 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I think we understand the envelope of the solutions, but we have to stabilize three design choices first:

1) Is the server mode important for the scenarios that we are thinking about?

2) Do we care about compatibility with the existing DNS-SD formats?

3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.)

We can easily write a spec that works without server mode, using binary formats, and runs as an app library. That's basically Bob's design, with an optional tweak to add an hint and minimize the CPU cost of trial decryption. We could also tweak the same spec and make it somehow fit in DNS formats, with a liberal usage of TXT records, but I don't know whether that's justified. We do not have a consensus on a server based solution, let alone on a server based solution that would reuse DNS servers. 

Basically, the best way for the chairs and the working group to help is to focus the work on a key scenario, and answer the three questions above.

-- Christian Huitema


On 2/26/2019 9:35 AM, David Schinazi wrote:
Thanks for kicking this discussion off again, Chris!

Bob, Christian, is there anything the chairs can do to facilitate making progress towards a joint proposal before Prague?

Thanks,
David

On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood <christopherwood07@gmail.com> wrote:
(Paging back in discussions from the meeting...)

On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <bradley@apple.com> wrote:
>
> I'm a little unclear what is being considered single-stage vs two-stage. How is single-stage able to send encrypted without knowing the destination? Is it encrypting a query with an asymmetric private key and multicasting? Or does single-stage refer to the predictable nonce approach? I was considering predictable nonce's two-stage because it has to first discover known peer service instances (stage 1) then perform encrypted queries/responses (stage 2).

If I understand and remember correctly, the single stage approach
would encrypt the service ID in the first query using the recipient's
public key, along with the predictable nonce generated using the
sender's public key. The response would contain the address of the
service in question. If we are concerned with the dictionary attack
mentioned earlier, a second round is required.

I assume the joint design with you, Christian, and Daniel will attempt
to find an appropriate balance here.

Best,
Chris

> Regarding the discussion:
>
> 1. Server mode. My proposal doesn't have a good way to support it. Normal server mode wasn't an important use case for me, but sleep proxy support would be nice. I just don't know how to do it yet, at least not without giving the sleep proxy your keys.
>
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is each device advertising a service instance for each pairing. The network I'm on now has 300+ devices and if each one has 50 friends, that's 15000 service instances on the network, which seems very high.
>
> I tried to reduce this by each device only advertising itself via multicast and then everything else is unicast. The first part of key exchange was also rolled into the advertisement packet to allow a single query packet and single response packet while still maintaining forward secrecy and per-pairing confidentiality.
>
> 3. CPU cost. This seems to be a comparison between more packets, but lower per-packet cost (in the per-pairing service instance model where predictable nonce hashes are precomputed) vs fewer packets, but more expensive per-packet signature verification. The two main use cases I was considering were home networks (where neither traffic nor CPU is likely to be an issue due to the small number of devices) and busy enterprise networks (office, dorm, coffee shop), which I assumed would be more powerful devices (laptops, phones, servers) where reducing traffic would be more important than the CPU usage for checking multicast probes.
>
> 4. One privacy concern regarding predictable nonces is that it would allow spoofing. Anyone with your public key could generate your predictable nonce. It could also enable friend relationships to be recovered. Maybe not a huge concern, but something to consider. Even the signature approach has a replay vulnerability, but it's time bounded.
>
> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s
>
> During that discussion, the room reached consensus on the following items:
>
> 1) single-stage approach -- Up until now, we were considering two approaches: single-stage (send encrypted and authenticated service identifier, receive encrypted and authenticated service response) and two-stage (send encryption and authenticated identifier, receive encrypted and authenticated response, derive secrets, send and receive subsequent queries encrypted using derived secrets). There was consensus in the room to go with the single-stage approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key exchange mechanism such as TLS. There was consensus in the room that we do not need TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all input and compound it into a single document and only advance that one. We will use draft-ietf-dnssd-privacy since that document has already been adopted by the working group. Christian Huitema has offered for Bob Bradley to join as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12-02.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--------------5A58524AA7FB6C22B43F9633-- From nobody Wed Feb 27 12:18:11 2019 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 DC3D61310AC for ; Wed, 27 Feb 2019 12:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qLysH05GwCfN for ; Wed, 27 Feb 2019 12:18:06 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 67ACD126C01 for ; Wed, 27 Feb 2019 12:18:06 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id a3so8520095pff.11 for ; Wed, 27 Feb 2019 12:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9T7MpwQh7q3wur3Ch0vT0aSoJsywnLPab4IC5gxqxPs=; b=Sn/IpvlRGKsE8YBAgX3CA/HlRzKOCx4t1GTOwC/cQDg2VAf6W12OxhQB8qQqwLTYoZ /Xb7XV66K4Z2DDleZu+yHoMgwCW49Qf3zru+koEDWGiyHe2uvOkpCUhhrFbifOtinXqB LYJ7/85MHbuL6gq15ydkCi37YCXbzr+7S3DSlWfwzsTyjIjGMBl53XmAuG6UP3RyA4FK O89K7a+HLXNJqDcbswDH7cNl7HPC6RkASWKQdAs3d9gNaIsrjCZC5KrHvIa6UVOAu0OM ZHA9Mzbj5SjQvETTi8UDweLZBtiqY6NiHUCqboUYtszMdtIVNAa0a6RcpRHWkDaKrwUV kAKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9T7MpwQh7q3wur3Ch0vT0aSoJsywnLPab4IC5gxqxPs=; b=Eo4pxypV2QhyB2UU6OygMjlGAG9BVxhRIITVWabCLOc5X8W1wJasNgMhYfErf0365z pFvs3CDmSB6WM54DjsPDLOmZK57GzKkR+fKnCSHpZFTNH+kPv4f7XWxa7/K8sIAsYJRV rn20hlirYtK2bmGhQ5VXFrpCkTu8DlE264h6paO77qMMPJ4D/TivyOBSMVzXKs7WnRVO ETbFPKzSeJqo8njj7mRsmQyl7wKFsMqsg6uXmXi0aLZ/fXW/IYm3NaU7uOwT94sbgBbk M6FgSGzzp0+So3LRDrtQLgrAb94CzzjGQVN8K5kIm647xKi759C50PAonvzORjWWEuNT UmqQ== X-Gm-Message-State: AHQUAuaO33IpiWV49hqx9WYEAoM+wsh2J+0Pg2iJpaPqEZdJLytoAKn7 fEkSchN+vhwgvS7eztlrin9Op1u2ItjpEx7Y/iw= X-Google-Smtp-Source: AHgI3IZIlbcQRTp1ehBgrFOg3/4a4b8fEn5EwbT60pOVRJdwzQwklBg+0oprskDJ7Ioh1cUK66/VYfL/9JTRmgkSjpE= X-Received: by 2002:a65:63c2:: with SMTP id n2mr4658966pgv.439.1551298685517; Wed, 27 Feb 2019 12:18:05 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> In-Reply-To: From: David Schinazi Date: Wed, 27 Feb 2019 12:17:54 -0800 Message-ID: To: Christian Huitema Cc: Christopher Wood , Bob Bradley , DNSSD Content-Type: multipart/alternative; boundary="0000000000001745150582e5dfd5" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 20:18:10 -0000 --0000000000001745150582e5dfd5 Content-Type: text/plain; charset="UTF-8" Thanks for writing this up Christian. I went through the minutes of our last in-person meeting in Bangkok and while we did not explicitly ask for consensus then, I got a feeling that the sense in the room was: 1) Is the server mode important for the scenarios that we are thinking about? - No one in the room came out strongly in favor of server mode - Server mode would add complexity My personal recommendation: we declare server mode out of scope for now. 2) Do we care about compatibility with the existing DNS-SD formats? - No one in the room came out strongly in favor of this - It was mentioned it would be nice to have but not critical - This would cause some security tradeoffs regarding hash size My personal recommendation: we declare compatibility with existing formats out of scope for now. 3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.) - We had briefly discussed this at IETF 100 in Singapore following Stuart's discussion of requirements: https://tools.ietf.org/html/draft-cheshire-dnssd-privacy-considerations-01#section-3 - I recall there was support in the room for having finer granularity such as per-app My personal recommendation: we focus on per-app for now. Based on the above, as chair, I'm proposing we move forward with a reduced scope solution for now, that is without server mode, using binary formats, and runs as an app library. To clarify, this wouldn't mean we won't try to build a follow-up solution for those requirements later, this is just meant as framing to help us make progress towards a concrete proposal. Please share your opinions on this potential approach. Thanks, David On Wed, Feb 27, 2019 at 10:35 AM Christian Huitema wrote: > I think we understand the envelope of the solutions, but we have to > stabilize three design choices first: > > 1) Is the server mode important for the scenarios that we are thinking > about? > > 2) Do we care about compatibility with the existing DNS-SD formats? > > 3) Do we want private discovery to work as a system component, or as an > app library? (a.k.a. per device or per app.) > > We can easily write a spec that works without server mode, using binary > formats, and runs as an app library. That's basically Bob's design, with an > optional tweak to add an hint and minimize the CPU cost of trial > decryption. We could also tweak the same spec and make it somehow fit in > DNS formats, with a liberal usage of TXT records, but I don't know whether > that's justified. We do not have a consensus on a server based solution, > let alone on a server based solution that would reuse DNS servers. > > Basically, the best way for the chairs and the working group to help is to > focus the work on a key scenario, and answer the three questions above. > > -- Christian Huitema > > > On 2/26/2019 9:35 AM, David Schinazi wrote: > > Thanks for kicking this discussion off again, Chris! > > Bob, Christian, is there anything the chairs can do to facilitate making > progress towards a joint proposal before Prague? > > Thanks, > David > > On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood < > christopherwood07@gmail.com> wrote: > >> (Paging back in discussions from the meeting...) >> >> On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley wrote: >> > >> > I'm a little unclear what is being considered single-stage vs >> two-stage. How is single-stage able to send encrypted without knowing the >> destination? Is it encrypting a query with an asymmetric private key and >> multicasting? Or does single-stage refer to the predictable nonce approach? >> I was considering predictable nonce's two-stage because it has to first >> discover known peer service instances (stage 1) then perform encrypted >> queries/responses (stage 2). >> >> If I understand and remember correctly, the single stage approach >> would encrypt the service ID in the first query using the recipient's >> public key, along with the predictable nonce generated using the >> sender's public key. The response would contain the address of the >> service in question. If we are concerned with the dictionary attack >> mentioned earlier, a second round is required. >> >> I assume the joint design with you, Christian, and Daniel will attempt >> to find an appropriate balance here. >> >> Best, >> Chris >> >> > Regarding the discussion: >> > >> > 1. Server mode. My proposal doesn't have a good way to support it. >> Normal server mode wasn't an important use case for me, but sleep proxy >> support would be nice. I just don't know how to do it yet, at least not >> without giving the sleep proxy your keys. >> > >> > 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy >> is each device advertising a service instance for each pairing. The network >> I'm on now has 300+ devices and if each one has 50 friends, that's 15000 >> service instances on the network, which seems very high. >> > >> > I tried to reduce this by each device only advertising itself via >> multicast and then everything else is unicast. The first part of key >> exchange was also rolled into the advertisement packet to allow a single >> query packet and single response packet while still maintaining forward >> secrecy and per-pairing confidentiality. >> > >> > 3. CPU cost. This seems to be a comparison between more packets, but >> lower per-packet cost (in the per-pairing service instance model where >> predictable nonce hashes are precomputed) vs fewer packets, but more >> expensive per-packet signature verification. The two main use cases I was >> considering were home networks (where neither traffic nor CPU is likely to >> be an issue due to the small number of devices) and busy enterprise >> networks (office, dorm, coffee shop), which I assumed would be more >> powerful devices (laptops, phones, servers) where reducing traffic would be >> more important than the CPU usage for checking multicast probes. >> > >> > 4. One privacy concern regarding predictable nonces is that it would >> allow spoofing. Anyone with your public key could generate your predictable >> nonce. It could also enable friend relationships to be recovered. Maybe not >> a huge concern, but something to consider. Even the signature approach has >> a replay vulnerability, but it's time bounded. >> > >> > On Nov 14, 2018, at 5:37 PM, David Schinazi >> wrote: >> > >> > Hello everyone, >> > >> > It the room at IETF 103, there was a very productive discussion about >> DNSSD privacy: >> > https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s >> > >> > During that discussion, the room reached consensus on the following >> items: >> > >> > 1) single-stage approach -- Up until now, we were considering two >> approaches: single-stage (send encrypted and authenticated service >> identifier, receive encrypted and authenticated service response) and >> two-stage (send encryption and authenticated identifier, receive encrypted >> and authenticated response, derive secrets, send and receive subsequent >> queries encrypted using derived secrets). There was consensus in the room >> to go with the single-stage approach. >> > >> > 2) Use of TLS -- The single-stage approach no longer requires a key >> exchange mechanism such as TLS. There was consensus in the room that we do >> not need TLS as part of this protocol. >> > >> > 3) Evolution of documents -- It was proposed that we would take all >> input and compound it into a single document and only advance that one. We >> will use draft-ietf-dnssd-privacy since that document has already been >> adopted by the working group. Christian Huitema has offered for Bob Bradley >> to join as co-author if Bob would like. >> > >> > If you disagree with any of these points, please say so before >> 2018-12-02. >> > >> > Thanks, >> > David >> > _______________________________________________ >> > dnssd mailing list >> > dnssd@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnssd >> > >> > >> > _______________________________________________ >> > dnssd mailing list >> > dnssd@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnssd >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > > _______________________________________________ > dnssd mailing listdnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd > > --0000000000001745150582e5dfd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks = for writing this up Christian.

I went through the minutes of our last in-person meeting in Bang= kok=C2=A0and while we did not
explicitly ask for = consensus then, I got a feeling that the sense in the room was:

1) Is the server mode important for the= scenarios that we are thinking about?
=C2=A0 =C2=A0 - No one in = the room came out strongly in favor of server mode
=C2=A0 =C2=A0 = - Server mode would add complexity

=C2=A0 =C2=A0 M= y personal recommendation: we declare server mode out of scope for now.

2) Do we care about compatibility with the existing D= NS-SD formats?
=C2=A0 =C2=A0 - No one in the room came out strong= ly in favor of this
=C2=A0 =C2=A0 - It was mentioned it would= be nice to have but not critical
=C2=A0 =C2=A0 - This would caus= e some security tradeoffs regarding hash size

=C2= =A0 =C2=A0 My personal recommendation: we declare compatibility with existi= ng formats out of scope for now.

3) Do we want= private discovery to work as a system component, or as an app library? (a.= k.a. per device or per app.)
=C2=A0 =C2=A0 - We had briefly= discussed this at IETF 100 in Singapore following Stuart's discussion = of requirements:
=C2=A0 =C2=A0 - I recall there was supp= ort in the room for having finer granularity such as per-app

=
=C2=A0 =C2=A0 My personal recommendation: we focus on per-app fo= r now.

Based on the above, as chair, I'm p= roposing we move forward with a reduced scope solution for now,
t= hat is without server mode, using binary formats, and runs as an app librar= y.
To clarify, this wouldn't mean we won't try to bui= ld a follow-up solution for those requirements later,
this is jus= t meant as framing to help us make progress towards a concrete proposal.

Please share your opinions on this potential approac= h.

Thanks,
David
=

= On Wed, Feb 27, 2019 at 10:35 AM Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20

I think we understand the envelope of the solutions, but we have to stabilize three design choices first:

1) Is the server mode important for the scenarios that we are thinking about?

2) Do we care about compatibility with the existing DNS-SD formats?

3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.)

We can easily write a spec that works without server mode, using binary formats, and runs as an app library. That's basically Bob&= #39;s design, with an optional tweak to add an hint and minimize the CPU cost of trial decryption. We could also tweak the same spec and make it somehow fit in DNS formats, with a liberal usage of TXT records, but I don't know whether that's justified. We do not= have a consensus on a server based solution, let alone on a server based solution that would reuse DNS servers.=C2=A0

Basically, the best way for the chairs and the working group to help is to focus the work on a key scenario, and answer the three questions above.

-- Christian Huitema


On 2/26/2019= 9:35 AM, David Schinazi wrote:
=20
Thanks for kicking this discussion off again, Chris!

Bob, Christian, is there anything the chairs can do to facilitate making progress towards a joint proposal before Prague?

Thanks,
David

On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood <christopherwood07@gmail.com> wrote:
(Paging back in discussions from the meeting...)

On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <bradley@apple.com> wrote:
>
> I'm a little unclear what is being considered single-stage vs two-stage. How is single-stage able to send encrypted without knowing the destination? Is it encrypting a query with an asymmetric private key and multicasting? Or does single-stage refer to the predictable nonce approach? I was considering predictable nonce's two-stage because it has to first discover known peer service instances (stage 1) then perform encrypted queries/responses (stage 2).

If I understand and remember correctly, the single stage approach
would encrypt the service ID in the first query using the recipient's
public key, along with the predictable nonce generated using the
sender's public key. The response would contain the address o= f the
service in question. If we are concerned with the dictionary attack
mentioned earlier, a second round is required.

I assume the joint design with you, Christian, and Daniel will attempt
to find an appropriate balance here.

Best,
Chris

> Regarding the discussion:
>
> 1. Server mode. My proposal doesn't have a good way to support it. Normal server mode wasn't an important use case for me, but sleep proxy support would be nice. I just don't know how to do it yet, at least not without giving the sleep proxy your keys.
>
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is each device advertising a service instance for each pairing. The network I'm on now has 300+ devices and if each one has 50 friends, that's 15000 service instances on the network, which seems very high.
>
> I tried to reduce this by each device only advertising itself via multicast and then everything else is unicast. The first part of key exchange was also rolled into the advertisement packet to allow a single query packet and single response packet while still maintaining forward secrecy and per-pairing confidentiality.
>
> 3. CPU cost. This seems to be a comparison between more packets, but lower per-packet cost (in the per-pairing service instance model where predictable nonce hashes are precomputed) vs fewer packets, but more expensive per-packet signature verification. The two main use cases I was considering were home networks (where neither traffic nor CPU is likely to be an issue due to the small number of devices) and busy enterprise networks (office, dorm, coffee shop), which I assumed would be more powerful devices (laptops, phones, servers) where reducing traffic would be more important than the CPU usage for checking multicast probes.
>
> 4. One privacy concern regarding predictable nonces is that it would allow spoofing. Anyone with your public key could generate your predictable nonce. It could also enable friend relationships to be recovered. Maybe not a huge concern, but something to consider. Even the signature approach has a replay vulnerability, but it's time bounded. >
> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com<= /a>> wrote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
> https://www.youtube.com/w= atch?v=3DhPuTD19R-uQ&t=3D28m43s
>
> During that discussion, the room reached consensus on the following items:
>
> 1) single-stage approach -- Up until now, we were considering two approaches: single-stage (send encrypted and authenticated service identifier, receive encrypted and authenticated service response) and two-stage (send encryption and authenticated identifier, receive encrypted and authenticated response, derive secrets, send and receive subsequent queries encrypted using derived secrets). There was consensus in the room to go with the single-stage approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key exchange mechanism such as TLS. There was consensus in the room that we do not need TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all input and compound it into a single document and only advance that one. We will use draft-ietf-dnssd-privacy since that document has already been adopted by the working group. Christian Huitema has offered for Bob Bradley to join as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12-02.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ie= tf.org
> https://www.ietf.org/mailman/listinfo/dns= sd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ie= tf.org
> https://www.ietf.org/mailman/listinfo/dns= sd

_______________________________________________
dnssd mailing list
dnssd@ietf.or= g
https://www.ietf.org/mailman/listinfo/dnssd=

= 
____________=
___________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf=
.org/mailman/listinfo/dnssd
--0000000000001745150582e5dfd5-- From nobody Wed Feb 27 12:27:04 2019 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 40DEF1310A8 for ; Wed, 27 Feb 2019 12:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 o0iQ4avZQxSq for ; Wed, 27 Feb 2019 12:27:00 -0800 (PST) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 890A512426A for ; Wed, 27 Feb 2019 12:27:00 -0800 (PST) Received: by mail-yw1-xc2b.google.com with SMTP id o184so9200927ywo.5 for ; Wed, 27 Feb 2019 12:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cBzr363oeiY2nWc2NUt8uCA2RA6HNb8pkb/9JzPHNXk=; b=gx26LmTAS7jOLbGkhE0hcoUqJ2r13w0Id+vaH8DgHh3R14G9WQVyhUT7t1sn3OhBoN 4Sxi78Q4N9okH5Qi9QcpxeMniyUcpqEEVsOwxWMwFoQU9U68YTcbuH46y3Vz8L7Xlnwh qqqPCqPZerBxgZPA0IoPp0DKOPQHEwceRsVO4facSoAyrCYUIyPHdv5QYABdrzIfe9Gw xC+9I1VfJ01yVevLAylyE8Dj/1uJLH4cDa7i0uRcFHdCsrAGiNYMp7uCZxiBSqjU3D29 HuSRdrqDnCuFzArydQWtmD60DOKp7CaV38qYjs7k48F3DiZUkDySsBzOr4sVEA6NfWgp fjwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cBzr363oeiY2nWc2NUt8uCA2RA6HNb8pkb/9JzPHNXk=; b=N19et1RxGDiqErI6VGJQryQNigoPETZiTAG/gEhzeBc0WJl0UfTvkyC9qdCZz0hqXv OD+E3LC049x+BH70S8mU2w9HqU2ay4b5zRs9ziNGw5HbNXmWqmr+i1wIKg51I1H6mVEN c/FXlYUL7YpWBMVImF5EquwdC1TrlnRjrJS5vbYTeULRNXldnz1Xg/CgmDCPD/R4so6R OoKLPM1lwSqJIdxhAF/8nXrrlJYztkC8YbH22zSQOM5jOlyhk8hcElB+CNaKCD7gBOLM YqZVHW4/kw3TU0wR7Jdd15X5taZvUPTNNrex141DoYA2WO1c91MZzbZMtnFQT51YMwv1 /nlw== X-Gm-Message-State: AHQUAuZXF2BOvK4zClZ0D6239C93CWj6j7Hps/NwfobSpwwbyqERUsmL nlh1WOqACYCbXQrrzkAHRzexa64Ac8sDGQVE+3Y= X-Google-Smtp-Source: AHgI3Ib54b9NJigQjmDxV7vnqrgRj6jSDt5a1JZHcrnD7Ds3zTed09HB9nuaMfvbMuTyngeJTPM3+iys/+gV3YGCvpQ= X-Received: by 2002:a81:83c1:: with SMTP id t184mr2799069ywf.350.1551299219442; Wed, 27 Feb 2019 12:26:59 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 12:26:48 -0800 Message-ID: To: David Schinazi Cc: Christian Huitema , Bob Bradley , DNSSD Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 20:27:02 -0000 On Wed, Feb 27, 2019 at 12:18 PM David Schinazi wrote: > > Thanks for writing this up Christian. > > I went through the minutes of our last in-person meeting in Bangkok and while we did not > explicitly ask for consensus then, I got a feeling that the sense in the room was: > > 1) Is the server mode important for the scenarios that we are thinking about? > - No one in the room came out strongly in favor of server mode > - Server mode would add complexity > > My personal recommendation: we declare server mode out of scope for now. > > 2) Do we care about compatibility with the existing DNS-SD formats? > - No one in the room came out strongly in favor of this > - It was mentioned it would be nice to have but not critical > - This would cause some security tradeoffs regarding hash size > > My personal recommendation: we declare compatibility with existing formats out of scope for now. > > 3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.) > - We had briefly discussed this at IETF 100 in Singapore following Stuart's discussion of requirements: > https://tools.ietf.org/html/draft-cheshire-dnssd-privacy-considerations-01#section-3 > - I recall there was support in the room for having finer granularity such as per-app > > My personal recommendation: we focus on per-app for now. > > Based on the above, as chair, I'm proposing we move forward with a reduced scope solution for now, > that is without server mode, using binary formats, and runs as an app library. > To clarify, this wouldn't mean we won't try to build a follow-up solution for those requirements later, > this is just meant as framing to help us make progress towards a concrete proposal. > > Please share your opinions on this potential approach. +1 This sounds reasonable to me! Best, Chris From nobody Wed Feb 27 14:17:46 2019 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 1330213116C for ; Wed, 27 Feb 2019 14:17:45 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 spMJNGEWJsF5 for ; Wed, 27 Feb 2019 14:17:42 -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 98C581288BD for ; Wed, 27 Feb 2019 14:17:42 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gz7WG-0008jt-3w for dnssd@ietf.org; Wed, 27 Feb 2019 23:17:40 +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 ) id 1gz7WA-00015l-3W for dnssd@ietf.org; Wed, 27 Feb 2019 17:17:38 -0500 Received: (qmail 30842 invoked from network); 27 Feb 2019 22:17:25 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Feb 2019 22:17:25 -0000 To: Christopher Wood , David Schinazi Cc: DNSSD , Bob Bradley References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> From: Christian Huitema 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: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> Date: Wed, 27 Feb 2019 14:17:11 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.12) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5g6qMy+aalatHfwf4tHdoGl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax9J9S/PAnLr4NJ6WrDCHf+FDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShlzrnA5L1r+ED N9MwqSUyichqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+ZbV1QYTPnZGbiCKnPeJqXuDg5/bq7ChmPMN Ycw1QSmR4KogojthJ2uTHxdVtUF4g50ATGERfTP6O+oW/gcdEVBm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiukzbVwTlpzEqQskUS84syO+NTKQHNkjJg8xvPcdYB8Xlm45eDKY0zTzJ2HG 4elPGf27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 22:17:45 -0000 OK. My next question is then how much commonality we want to have with TL= S. All solutions in this space involve sending a broadcast query that asks whether some peer is present. The query is secured using some secret only known to the peers. From the previous discussions, we sort of agreed that this secret should be a "discovery public key", with the special twist that this public key should in fact be kept secret. The exchange would typically be an ECDH exchange, something like that: * Client broadcast a query, containing its own ECDH half key, a nonce, a proof, and possibly a hint. * The proof is secured by a "discovery secret", obtained by combining the ECDH half key and the server's discovery key. The optional hint is a cryptographic hash of the coarse time and the discovery secret * All servers get the message. If the hint is present they can verify that the query targets them. If no hint is expected, or if the hint matches, they compute the discovery secret and verify the nonce. If it is not verified, they just drop the message. * The responding server confirms the connection, sends its own ECDH half key, derives a handshake secret, etc. I notice that this is extremely similar to the TLS handshake, and especially to the QUIC or DTLS handshakes when using ESNI encryption. One simple way to deliver the functionality would be, just define a TLS extension for the "discovery proof". And with that, we would have a secure and private way to establish a DTLS session or a QUIC connection. -- Christian Huitema On 2/27/2019 12:26 PM, Christopher Wood wrote: > On Wed, Feb 27, 2019 at 12:18 PM David Schinazi > wrote: >> Thanks for writing this up Christian. >> >> I went through the minutes of our last in-person meeting in Bangkok an= d while we did not >> explicitly ask for consensus then, I got a feeling that the sense in t= he room was: >> >> 1) Is the server mode important for the scenarios that we are thinking= about? >> - No one in the room came out strongly in favor of server mode >> - Server mode would add complexity >> >> My personal recommendation: we declare server mode out of scope fo= r now. >> >> 2) Do we care about compatibility with the existing DNS-SD formats? >> - No one in the room came out strongly in favor of this >> - It was mentioned it would be nice to have but not critical >> - This would cause some security tradeoffs regarding hash size >> >> My personal recommendation: we declare compatibility with existing= formats out of scope for now. >> >> 3) Do we want private discovery to work as a system component, or as a= n app library? (a.k.a. per device or per app.) >> - We had briefly discussed this at IETF 100 in Singapore following= Stuart's discussion of requirements: >> https://tools.ietf.org/html/draft-cheshire-dnssd-privacy-consi= derations-01#section-3 >> - I recall there was support in the room for having finer granular= ity such as per-app >> >> My personal recommendation: we focus on per-app for now. >> >> Based on the above, as chair, I'm proposing we move forward with a red= uced scope solution for now, >> that is without server mode, using binary formats, and runs as an app = library. >> To clarify, this wouldn't mean we won't try to build a follow-up solut= ion for those requirements later, >> this is just meant as framing to help us make progress towards a concr= ete proposal. >> >> Please share your opinions on this potential approach. > +1 > > This sounds reasonable to me! > > Best, > Chris > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Feb 27 16:32:04 2019 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 426D11311F0 for ; Wed, 27 Feb 2019 16:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Oe0M4LcGFoEz for ; Wed, 27 Feb 2019 16:32:01 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 F1AC4130EEC for ; Wed, 27 Feb 2019 16:32:00 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id r188so9565105ywb.12 for ; Wed, 27 Feb 2019 16:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6elnUZP3REAXYYbRvtRKUTzVERnQrP5F7QeU4f321Hg=; b=kzBD7XvRFsN2Zt4LE8oSVebEcDtNBtdo+eFFbVWbKtsj3EgpatnwSIBQpFpQ7SEZjZ EBeyappl7JgGAr2wRIhFQnnlNjxDbWP91pKkRZC0KXpz43Y0dJmRMDUFWhhMzXgUBg+u ESbVn1cqOfV87gtDx7OtgSZMmiXvM8P/vEIRAeDLjz5oB5bylhAHAr3bpj6dN0mjBgfV 32ALtNIIZurqTD9kTLgfqwiqwEm1v8MJBFh3f6IqX8xiMo8oSkbE5eJmyWXHLCGP7/8c AxQwoBtK2oIWs8VshE2D8qq/BO1pf9yvMOfISC9ng5A180j2RVnfQWXdvu0om46UNw5e F43w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6elnUZP3REAXYYbRvtRKUTzVERnQrP5F7QeU4f321Hg=; b=IYZZ2U9M8fxkaGtFIvoaC/HNm2qdV28W1OwsAQlJxp55V3ZDez4OcoZvRmgZdOMVg+ 2LLnQEkcG7G86aXTtYsfWhMjRH5pI7pOXuH6nH4SvMoNNYlvr4206o5eO1KgZzyXGCtX sD4EQPsaP48kb7XybkKhRKonxxA4zej36Fid4qKS5T7fQX6uVcJGSGxS8ZwNxD+6wYrX NZ2NnePTlmtI0/9MVpStbhyAxw3GkrK8EdASlHDXZqf+EWWs6xg1Eh7yXaMYcPMku3D5 4vMnCZfFBfxMGzwKFYbmDtIuzdAhK7JN4LumZnxkDPrHZDzafCHI+O5Kr/HVZbIsHqkZ FsmQ== X-Gm-Message-State: AHQUAua1oPZWpJRpTLeGQIlZshKTe8Rwm45G4rP97EzGdC5ujQ57b97d C8m6ga0n5Un0gWRWv3aFJ6NEKQGoneq0EE8+RMQ= X-Google-Smtp-Source: AHgI3IY23mBKsj0kBkrs37mZZ+n1JFMJQ9vQ2sr3EvVBMFKMqWybB+xfpTYC6VYFJeqNKXwpwyrTWX5oZGNNea63elc= X-Received: by 2002:a81:2544:: with SMTP id l65mr3532988ywl.263.1551313919303; Wed, 27 Feb 2019 16:31:59 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> In-Reply-To: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> From: Christopher Wood Date: Wed, 27 Feb 2019 16:31:48 -0800 Message-ID: To: Christian Huitema Cc: David Schinazi , DNSSD , Bob Bradley Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 00:32:03 -0000 On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema wrote: > > OK. My next question is then how much commonality we want to have with TLS. > > All solutions in this space involve sending a broadcast query that asks > whether some peer is present. The query is secured using some secret > only known to the peers. From the previous discussions, we sort of > agreed that this secret should be a "discovery public key", with the > special twist that this public key should in fact be kept secret. The > exchange would typically be an ECDH exchange, something like that: > > * Client broadcast a query, containing its own ECDH half key, a nonce, a > proof, and possibly a hint. > > * The proof is secured by a "discovery secret", obtained by combining > the ECDH half key and the server's discovery key. The optional hint is a > cryptographic hash of the coarse time and the discovery secret > > * All servers get the message. If the hint is present they can verify > that the query targets them. If no hint is expected, or if the hint > matches, they compute the discovery secret and verify the nonce. If it > is not verified, they just drop the message. > > * The responding server confirms the connection, sends its own ECDH half > key, derives a handshake secret, etc. > > I notice that this is extremely similar to the TLS handshake, and > especially to the QUIC or DTLS handshakes when using ESNI encryption. > One simple way to deliver the functionality would be, just define a TLS > extension for the "discovery proof". And with that, we would have a > secure and private way to establish a DTLS session or a QUIC connection. 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. Best, Chris From nobody Wed Feb 27 16:45:53 2019 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 0DB79131204 for ; Wed, 27 Feb 2019 16:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QK6-ojGNAlKx for ; Wed, 27 Feb 2019 16:45:50 -0800 (PST) Received: from mail-yw1-xc43.google.com (mail-yw1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (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 BEE5B1311FF for ; Wed, 27 Feb 2019 16:45:49 -0800 (PST) Received: by mail-yw1-xc43.google.com with SMTP id i204so7235435ywb.0 for ; Wed, 27 Feb 2019 16:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BVUeIfMTYXnK81xYK9WKgIM9uY5WsM2k1MvDcgNTzdc=; b=bLm6SMIefPXYeyxlwBxLUm50sKv3w9tev0C0lpc5kMrKZN9lCsSETKGWa39dT/4azK v0WAeyirc1QqRjTvlzz2iTDSS+P4mOJvzzHfjo6hVks7Y7W2iSmRhsbneEFpxZwcU/RG aynE2OcIahzen4u/Xi+fuCcDu+cMIOSOBQbGGcdjFulBoUm3eE9l/oYgEL67c5FQznvY 9nnKvCpZzoCv1wHQoyff+soNPYxEFORs+PAIZ9DHtzC15pJqOw+MFH9iHdvtzsCvju3S CwRocBHEcFMEtXsGOVNJWa0Xh6t9R/qBIcBXB3lHo8AUMElBc6bp9SiSoVsaYZ3ZeHFg iYKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BVUeIfMTYXnK81xYK9WKgIM9uY5WsM2k1MvDcgNTzdc=; b=kH1oRDHwGy73JSJDRcCHMxIgpySgT4MSOJKoAQfKPXbMeRfsjxVQOxL5i2n3XIfqKn u/KBbgXN3mT9H2ewrq7wFFvbiyFCVzSJjQLwXvxuuy1pk/nrSwLlqt+o8fslBIhpeSm4 Eoj4FiZZEJFscffB/aECROdWwolt2PgUYUIHO3GKFFkVSxQdTHwUjoWGDGFmq8rEedAp S852A6Xs6Hk5ki+BS3zxCeUsgafv4U4LUMYcmX5BGibNWOsLFmj3Ho7IuxKJGWItvRl4 pkPjFphIe0rCiV056GxulTmaQK9L+sdy7BdKDs8ZX3SYhKsk6HshYXnVTLC1IPTPHkOG 8+RA== X-Gm-Message-State: AHQUAuYd2bIfPVbRJ09nbvyQhrltrI6TAOGtZAdX924+q5lN8i569OYh /sMlEesyRfg9eO+QuhEDuXsXcVme9V0CImo46qE= X-Google-Smtp-Source: AHgI3IaksOyyNAn7SA4bZxs1XfHBrEAqQpzUptmHJQNUIHmUiTRAGc1r2FaGHOhFhNHKZzN3B4mW73GBla4UieYEFoc= X-Received: by 2002:a5b:447:: with SMTP id s7mr4357498ybp.168.1551314748345; Wed, 27 Feb 2019 16:45:48 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 16:45:37 -0800 Message-ID: To: Christian Huitema Cc: David Schinazi , DNSSD , Bob Bradley Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 00:45:52 -0000 On Wed, Feb 27, 2019 at 4:31 PM Christopher Wood wrote: > > On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema wrote: > > > > OK. My next question is then how much commonality we want to have with TLS. > > > > All solutions in this space involve sending a broadcast query that asks > > whether some peer is present. The query is secured using some secret > > only known to the peers. From the previous discussions, we sort of > > agreed that this secret should be a "discovery public key", with the > > special twist that this public key should in fact be kept secret. The > > exchange would typically be an ECDH exchange, something like that: > > > > * Client broadcast a query, containing its own ECDH half key, a nonce, a > > proof, and possibly a hint. > > > > * The proof is secured by a "discovery secret", obtained by combining > > the ECDH half key and the server's discovery key. The optional hint is a > > cryptographic hash of the coarse time and the discovery secret > > > > * All servers get the message. If the hint is present they can verify > > that the query targets them. If no hint is expected, or if the hint > > matches, they compute the discovery secret and verify the nonce. If it > > is not verified, they just drop the message. > > > > * The responding server confirms the connection, sends its own ECDH half > > key, derives a handshake secret, etc. > > > > I notice that this is extremely similar to the TLS handshake, and > > especially to the QUIC or DTLS handshakes when using ESNI encryption. > > One simple way to deliver the functionality would be, just define a TLS > > extension for the "discovery proof". And with that, we would have a > > secure and private way to establish a DTLS session or a QUIC connection. > > 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. Best, Chris From nobody Wed Feb 27 16:48:59 2019 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 5FAB712D827 for ; Wed, 27 Feb 2019 16:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qJzp3yA_MYYn for ; Wed, 27 Feb 2019 16:48:54 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 AC7A6126C15 for ; Wed, 27 Feb 2019 16:48:54 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id q206so8802138pgq.4 for ; Wed, 27 Feb 2019 16:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Egw8m+TuNmVdXU6cHuTiu3EmvUgRjNGgq2tOWRKZ09g=; b=rW7lPkoVLkcSTET1Vf/SZYAK6q6nS4jFITARErxj7jwlM/Z06ey5+TOpt8EksEGlmp Ww6bCgCDNTGTenOSAKN8ttIbl+oyTYXk7XCzLtSylGAR5eX94iF+GAmXbudkViYh3WPb kuLw8WVaCs2sh/olt/Divgpi5+lBMdAT7KmCl3r7Wj9OaPYwcD1qx91EPbNErQI9mblQ sIQ+MM30Map6/k0VpOCYgEDiG83PCavA828fE1E7SoABpo5RYkdQ2wOl3hsh/6JZ3GaX EDsNd8xHgf0Um8p7SsVWNMTczmakdalKo2nEmbQ+MdfsTOED4SpFdNbEGt4Td0OB6zb6 y3XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Egw8m+TuNmVdXU6cHuTiu3EmvUgRjNGgq2tOWRKZ09g=; b=MlbNrvDYwrDJywQbtQSwGLBp9wFs6zoPyJV8yXYYXcKOGKWmnw360vdpR8P5TBQ6V2 BIB/txkmoSGZicx7zvl3kBLO2DElguGkAuBcps8AMUmRDSheDMkvHOxkY08uFq3p2bfa 1TqUnUkMDKtnAOCwzmG+O//0wT96i6NUcIAzbQV/EtF2hMIdas7x3rlPCQoXvPZ4iZPC MnvrsaWKnJA9DB5hOnTd+cKUGGdJmk3uZGvP1/x4ks1ixL9sW0XO8dyCM+3+Arjk8vFa VTNDep3bLNoRRn68J4mSkUKgy6sA7ncoScYf6VaqXXo9S6xdNEjh10I0j5aESCK73BS0 4p1w== X-Gm-Message-State: AHQUAub6M15mgjfXUdsot5ozF8A1cX93JIwLaDm7D6bC3IcOImyHoBgR 3E2UdTpFu69e8yL3RLn4CinFBuN5kgqvFz21rHQ= X-Google-Smtp-Source: AHgI3IbeoNhugpntZcmZoRdi92vNS67X+FtSn1bOzs9Z2Qg5wbKweCT+vbCeHPkZ6aMRjQgHSEzynYg1xsfgf6NsDIY= X-Received: by 2002:aa7:8012:: with SMTP id j18mr4799654pfi.42.1551314933706; Wed, 27 Feb 2019 16:48:53 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> In-Reply-To: From: David Schinazi Date: Wed, 27 Feb 2019 16:48:42 -0800 Message-ID: To: Christopher Wood Cc: Christian Huitema , DNSSD , Bob Bradley Content-Type: multipart/alternative; boundary="0000000000008ef3630582e9a729" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 00:48:58 -0000 --0000000000008ef3630582e9a729 Content-Type: text/plain; charset="UTF-8" Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it. David On Wed, Feb 27, 2019 at 4:45 PM Christopher Wood < christopherwood07@gmail.com> wrote: > On Wed, Feb 27, 2019 at 4:31 PM Christopher Wood > wrote: > > > > On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema > wrote: > > > > > > OK. My next question is then how much commonality we want to have with > TLS. > > > > > > All solutions in this space involve sending a broadcast query that asks > > > whether some peer is present. The query is secured using some secret > > > only known to the peers. From the previous discussions, we sort of > > > agreed that this secret should be a "discovery public key", with the > > > special twist that this public key should in fact be kept secret. The > > > exchange would typically be an ECDH exchange, something like that: > > > > > > * Client broadcast a query, containing its own ECDH half key, a nonce, > a > > > proof, and possibly a hint. > > > > > > * The proof is secured by a "discovery secret", obtained by combining > > > the ECDH half key and the server's discovery key. The optional hint is > a > > > cryptographic hash of the coarse time and the discovery secret > > > > > > * All servers get the message. If the hint is present they can verify > > > that the query targets them. If no hint is expected, or if the hint > > > matches, they compute the discovery secret and verify the nonce. If it > > > is not verified, they just drop the message. > > > > > > * The responding server confirms the connection, sends its own ECDH > half > > > key, derives a handshake secret, etc. > > > > > > I notice that this is extremely similar to the TLS handshake, and > > > especially to the QUIC or DTLS handshakes when using ESNI encryption. > > > One simple way to deliver the functionality would be, just define a TLS > > > extension for the "discovery proof". And with that, we would have a > > > secure and private way to establish a DTLS session or a QUIC > connection. > > > > 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. > > Best, > Chris > --0000000000008ef3630582e9a729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<chair hat off>
Given that our main target is lo= cal networks, I personally believe spending an extra round trip to prevent = dictionary attacks sounds worth it.

David

On = Wed, Feb 27, 2019 at 4:45 PM Christopher Wood <christopherwood07@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 27, 2019 at 4:= 31 PM Christopher Wood
<christ= opherwood07@gmail.com> wrote:
>
> On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema <huitema@huitema.net> wrote:=
> >
> > OK. My next question is then how much commonality we want to have= with TLS.
> >
> > All solutions in this space involve sending a broadcast query tha= t asks
> > whether some peer is present. The query is secured using some sec= ret
> > only known to the peers. From the previous discussions, we sort o= f
> > agreed that this secret should be a "discovery public key&qu= ot;, with the
> > special twist that this public key should in fact be kept secret.= The
> > exchange would typically be an ECDH exchange, something like that= :
> >
> > * Client broadcast a query, containing its own ECDH half key, a n= once, a
> > proof, and possibly a hint.
> >
> > * The proof is secured by a "discovery secret", obtaine= d by combining
> > the ECDH half key and the server's discovery key. The optiona= l hint is a
> > cryptographic hash of the coarse time and the discovery secret > >
> > * All servers get the message. If the hint is present they can ve= rify
> > that the query targets them. If no hint is expected, or if the hi= nt
> > matches, they compute the discovery secret and verify the nonce. = If it
> > is not verified, they just drop the message.
> >
> > * The responding server confirms the connection, sends its own EC= DH half
> > key, derives a handshake secret, etc.
> >
> > I notice that this is extremely similar to the TLS handshake, and=
> > especially to the QUIC or DTLS handshakes when using ESNI encrypt= ion.
> > One simple way to deliver the functionality would be, just define= a TLS
> > extension for the "discovery proof". And with that, we = would have a
> > secure and private way to establish a DTLS session or a QUIC conn= ection.
>
> 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 mutuall= y
> 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 thr= eat
> 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.

Best,
Chris
--0000000000008ef3630582e9a729-- From nobody Wed Feb 27 17:20:51 2019 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 DC107130EB3 for ; 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 ; 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 ; 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 ) 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 ) 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 ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 01:20:38 -0000 To: dnssd@ietf.org References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> From: Christian Huitema 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: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:20:50 -0000 This is a multi-part message in MIME format. --------------FD57F4C37E1EAFC7C94C6EA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 --------------FD57F4C37E1EAFC7C94C6EA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


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

--------------FD57F4C37E1EAFC7C94C6EA6-- From nobody Wed Feb 27 17:26:09 2019 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 64EE7130EAB for ; Wed, 27 Feb 2019 17:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fN097dodC7bz for ; Wed, 27 Feb 2019 17:26:06 -0800 (PST) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 708621277D2 for ; Wed, 27 Feb 2019 17:26:06 -0800 (PST) Received: by mail-yw1-xc2b.google.com with SMTP id 189so9797790ywi.3 for ; Wed, 27 Feb 2019 17:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+hCcd/5K8QEEEc8HsBAKdelX3Ezu71J02BOctr6XBuQ=; b=LRU05fqaqzlV0lJviEjO1nubD+pRaVBhufUYspfNKqrb/NWKAzW+EvU+SZhKOGeAzO deTmhjF1p6Fg9PizpXKATtD1kUKTWzi2zS0xZq/jyy4pkvB7n/wJhgzRg58OtIdVHRUC fd7l+pZUJ42Cc71NVc8kbVLsuFDt8XzGzVEilxCIgk9QKQEqQOJSeDIKtVtdWOb4GQdl /UgJ5gvQey1pNttSnRMuw0wTMC9YZ+Ds+lc9riE4zdep2UYYW6YmVzRk7pnFwdNjlNGj AGSP3u1QDYgbmA8ym+tcluWRl4x5XJCWBQDemU6Ipc3p+LsGC4HFr2Zx6vG3cZ60SlmX XKqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+hCcd/5K8QEEEc8HsBAKdelX3Ezu71J02BOctr6XBuQ=; b=FPafjofesWFO+5kHE1QdAyy5iK9WzsFoHXp1zcdUhO1qgiGj7rE8sDZ8WCee5geu5W O9EnHhrHcHNhj5wr5Dytc+iGtOnuk/l5LFrWxZvZStLZ67A83/S+5tPvKXEd+Zdq86Kd FUbp83lm2ROOGrhfQABFKeaAQCSY3U67mY/XP1jp/5IYjnu9WXpce5/CeT7wxlpvWADp DibHPfkSyqkBKwlboOg0m2rbGVlbwewotRIhwuWL8aQzN4E/dWL0N5/1RYWkmVX9wl5F A8faPeVNKcTcAL4gZIGm5CYf/A1ppljaqrvUBolrNTtu2A21ev0lZhcnk4WubckDps49 fHBA== X-Gm-Message-State: AHQUAubwU9IyRLyV3oannDF40Omg+91XPWnZS/RCdEQ5ghyaRKqsR0gF 1c3Z2zi3fhza4tjiwveTPvVS7Nwj9J9lycQRiOY= X-Google-Smtp-Source: AHgI3IZ+/rqEluNllFGCrMuwCfeCnKRULGFZviQFuMVwjPs5bNlg97Y3wm9wFza3gNswzsOGrSB2dtcEXz1Eh2XjGMw= X-Received: by 2002:a25:73d3:: with SMTP id o202mr4575012ybc.310.1551317165300; Wed, 27 Feb 2019 17:26:05 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <89ab9dfc-99a5-9522-201b-3713abf43575@huitema.net> In-Reply-To: <89ab9dfc-99a5-9522-201b-3713abf43575@huitema.net> From: Christopher Wood Date: Wed, 27 Feb 2019 17:25:54 -0800 Message-ID: To: Christian Huitema Cc: DNSSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:26:08 -0000 On Wed, Feb 27, 2019 at 5:20 PM Christian Huitema wro= te: > > > 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". Ah, well I was operating under the assumption that we were *not* using ESNI= . What is in the discovery proof, then? > 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 exp= ected 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 prototy= pe 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 proj= ect. The work is fairly minimal: > > 1) At the client, provision the server discovery key out of band at autho= rized clients, instead of the DNS lookup of the ESNI key of the client faci= ng server in the standard implementation; > > 2) At the server, accept the first packet in the exchange over a broadcas= t channel, > > 3) At the server, discard all ClientHello packets that do have an ESNI ex= tension 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 exch= ange, such as copying a nonce in the server response to demonstrate that th= e server correctly decrypted the ESNI. > > -- Christian Huitema > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Feb 27 17:37:00 2019 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 6FC3C130EAB for ; Wed, 27 Feb 2019 17:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, 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 1cVVp82Utits for ; Wed, 27 Feb 2019 17:36:57 -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 79C1C1277D2 for ; Wed, 27 Feb 2019 17:36:57 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx148.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzAd2-000TyR-ML for dnssd@ietf.org; Thu, 28 Feb 2019 02:36:54 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzAcx-0002Zv-Vn for dnssd@ietf.org; Wed, 27 Feb 2019 20:36:51 -0500 Received: (qmail 13573 invoked from network); 28 Feb 2019 01:36:47 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 01:36:47 -0000 To: David Schinazi , Christopher Wood Cc: DNSSD , Bob Bradley References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> From: Christian Huitema 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: <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> Date: Wed, 27 Feb 2019 17:36:46 -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: Content-Type: multipart/alternative; boundary="------------163F53E63442BBC505809B49" Content-Language: en-US X-Originating-IP: 168.144.250.231 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: ham X-Spampanel-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lt0b+qG9u/2SegrJ0n+gul602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax1IRRPwT+x9a/5Eo1S97R4lDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5I4iFfL0t/T+jmhQmmcESEaXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsi2uVu9e8T3JeB2VHikG6U0IaHgRVGa7DAKl0bmC/vskaHdPSuL1al0 T2M3dV8mLBVqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+TvNcd3HWUjlOEFEnWeTdqCDg5/bq7ChmPMN Ycw1QSmR2pZhBkLj9lP5LyiDd9I/dAalxprNaGd1cq9qqNTfLuBm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhijAHO4UjZyr3s8K1Hs5JOni+NTKQHNkjJg8xvPcdYB8XgK1T2S4h8DThwS4W K6Op7v27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:36:59 -0000 This is a multi-part message in MIME format. --------------163F53E63442BBC505809B49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2019 4:48 PM, David Schinazi wrote: > > Given that our main target is local networks, I personally believe > spending an extra round trip to prevent dictionary attacks sounds > worth it. I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=3D1 as= : struct { CipherSuite suite; KeyShareEntry key_share; opaque record_digest<0..2^16-1>; opaque encrypted_sni<0..2^16-1>; } ClientEncryptedSNI; The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest". The digest is used by servers to quickly identify the public key needed to encrypt the service name, and we don't want that. KeyShareEntry is very much the same element as the "ephemeral client key" in Bob's draft. The encrypted structure contains: struct { ServerNameList sni; opaque zeros[ESNIKeys.padded_length - length(sni)]; } PaddedServerNameList; struct { uint8 nonce[16]; PaddedServerNameList realSNI; } ClientESNIInner; Only the server can decrypt that, and echo the nonce in the encrypted server extension. The Service Name Identification is not sent in the clea= r. -- Christian Huitema --------------163F53E63442BBC505809B49 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/27/2019 4:48 PM, David Schinazi wrote:
<chair hat off>
Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it.

I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest". The digest is used by servers to quickly identify the public key needed to encrypt the service name, and we don't want that. KeyShareEntry is very much the same element as the "ephemeral client key" in Bob's draft.

The encrypted structure contains:

      struct {
          ServerNameList sni;
          opaque zeros[ESNIKeys.padded_length - length(sni)];
      } PaddedServerNameList;

      struct {
          uint8 nonce[16];
          PaddedServerNameList realSNI;
      } ClientESNIInner;

Only the server can decrypt that, and echo the nonce in the encrypted server extension. The Service Name Identification is not sent in the clear.

-- Christian Huitema






--------------163F53E63442BBC505809B49-- From nobody Wed Feb 27 17:40:31 2019 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 73D20130F13 for ; Wed, 27 Feb 2019 17:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 L_07zoOTZ2s0 for ; Wed, 27 Feb 2019 17:40:25 -0800 (PST) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 E1694130EF7 for ; Wed, 27 Feb 2019 17:40:24 -0800 (PST) Received: by mail-yw1-xc33.google.com with SMTP id 189so9819299ywi.3 for ; Wed, 27 Feb 2019 17:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KnEK9gMm4Y9MrMOyUrGwsI4PAnhrJCFPovF7zX+s8EE=; b=n+4yX8Uq6NSmlX67l4DyKnktRJv2fi9hKejhZo8fKyQ4pcWAebCA0pzmIYdBuz5AwE HJlWfZ4d0N6mLnnEnZKqu4Rtj+A9qoxkxvP00JBvfStw0KVczzZmKLVnDjm+YeAC/Dva J4oAoC+4LgDbb4Z5djvweHZL+kfX/1v2ffw69g32kWUU5gAhPpU8QdTIjiJoVG+W4AxR 6Wln71QfkGIfy1M6TcogWvXeCi9YRdissDzF3U24fP+xr0azfeqxXxV6PHVLlI+snIOv RQxKiFZOkZR9QZ57gmsDUcdHYD1vQh4YsZyzlTNB3n4vERjTpWgFBEBXAYc4ZhuGfRu+ C6kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KnEK9gMm4Y9MrMOyUrGwsI4PAnhrJCFPovF7zX+s8EE=; b=V0tEozE6ndPmPZfnyU63a8BYt6Te/VtXc3tAvvGrzG3TscRb4fqUpqQYTUW2Uafljp a3PxckqS/ZIzDDl2INxOXE+2ZjqM7SmrM3wXtLnBGLSis417qZnTXEdCUBih4aA4XnN0 lgWMz8ZydnapwP7zL/xyg/0bdP9irm4KFDIqrP64yP3CcR0IvbMMQVENZ0QQKzTKAInt O8hF8e4yIF8Q2KJiX2LwOG7/R1fknf93YZ/BKyk/dMcHZLLxRmud4l3gwVshqMJN7VwB RZSOc5ai+GgjMKQnmWVFP0/xY/ZBpJzyJoCIMgUwmY2TXE/e4Wwer+imfOJd+RiMwZi3 mOVw== X-Gm-Message-State: AHQUAub9jl895LwVVRkHgy4r0RK3/toZ/TN6E2EJkj6yrqZxW4I3ywA0 j/1Xs07t2MzR0xqVilsbENYNqa5gAB9vwybcxsY= X-Google-Smtp-Source: AHgI3IZqfU7P9auGPFmUr2A9XoO0RKn3QxwxjsvRrqcRVLZmhKmpbaBVRosFUwz5tKH0a4EYxxT3I697vkKqJON9NCY= X-Received: by 2002:a81:49d4:: with SMTP id w203mr3606287ywa.208.1551318023862; Wed, 27 Feb 2019 17:40:23 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> In-Reply-To: <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> From: Christopher Wood Date: Wed, 27 Feb 2019 17:40:12 -0800 Message-ID: To: Christian Huitema Cc: David Schinazi , DNSSD , Bob Bradley Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:40:30 -0000 On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema wrote: > > > On 2/27/2019 4:48 PM, David Schinazi wrote: > > > Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it. > > I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as: > > struct { > CipherSuite suite; > KeyShareEntry key_share; > opaque record_digest<0..2^16-1>; > opaque encrypted_sni<0..2^16-1>; > } ClientEncryptedSNI; > > The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest". This seems to highlight my main reservation about the 1-RTT approach. I think we ought not to complicate things and just pay the round trip. Best, Chris From nobody Wed Feb 27 17:58:39 2019 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 A081C130ECF for ; Wed, 27 Feb 2019 17:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, 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 ZbLuGHhuyieh for ; Wed, 27 Feb 2019 17:58:35 -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 10C14130ED1 for ; Wed, 27 Feb 2019 17:58:35 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx64.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzAxz-0008kW-Ru for dnssd@ietf.org; Thu, 28 Feb 2019 02:58:33 +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 ) id 1gzAxs-0004mD-8f for dnssd@ietf.org; Wed, 27 Feb 2019 20:58:28 -0500 Received: (qmail 6869 invoked from network); 28 Feb 2019 01:58:23 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 01:58:23 -0000 To: Christopher Wood Cc: David Schinazi , DNSSD , Bob Bradley References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> From: Christian Huitema 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: <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> Date: Wed, 27 Feb 2019 17:58:21 -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: Content-Type: multipart/alternative; boundary="------------9ED6F6931B535450FDD55751" 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: ham X-Spampanel-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qECSeh1quIO4HZK+Lxd88N602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxDeqxPVlb9ZxIvHAVfAyrMVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5O8DwfkFdMffakKgrcPlJVU5EpHPznVavQp4h 1cyzxbRC4xvs/7iGgDKhZ45D5vihvZAdx4vjUFLh0kXGIOazxFpgLxqZUFZdwbOLffZB9SIbeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80DrsibCyBr x+YtCB8oetqRijWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SK/lIPtlUiBhTzlv5XU8Y E2iH1Wgh6RAenBR+licROGabsoO+i5l1K3eqCcE+hdbrCyHNn4y5meVp0lPaP1BSw4tDk+Ou/8cr yaaZf7OJbNll7B1QQuoPmRqW5R/J2U16th3iHXgtR+Y1L+Zzkg9a2/EwurjXBahe19+jBD7VuIee yrhzWminYO4gRGXn3bDVvCoqfGflxbtjudA02/m3s17Er5njffaBp+i1irc0Olm4aeVKjbQuc4NX lvv7E2xuWc4drciUP2qUgRznOA6z9dmtxq+KXguN+ieQ8NTnnlRy2DNwOgV373pfDhBQ21OdM8gu ipSMnc4a1vOLkZpIfwYOSQC57rgJ01MshEpMs8z4YaYZ30wD+IYKdMuYOSaMo4eLRFi+U5i8mhS0 Ju9L9skPb2KLnZ2Xht3zA75VehhIcJfl9xjKxh+F8kIXLdZND3rjHB4Yc+TqdazcMI41sA2AfTJ2 5W/vzfaHf3wr2m4mbmeTgFKBgc4kmBS2brusOVZrHRzE6blhEo+mN1j1Fw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:58:38 -0000 This is a multi-part message in MIME format. --------------9ED6F6931B535450FDD55751 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2019 5:40 PM, Christopher Wood wrote: > On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema = wrote: >> On 2/27/2019 4:48 PM, David Schinazi wrote: >> >> >> Given that our main target is local networks, I personally believe spe= nding an extra round trip to prevent dictionary attacks sounds worth it. >> >> I am thinking of using the ESNI extension, or developing a very simila= r extension specifically for the purpose of private discovery. The ESNI e= xtension format is defined in https://datatracker.ietf.org/doc/draft-ietf= -tls-esni/?include_text=3D1 as: >> >> struct { >> CipherSuite suite; >> KeyShareEntry key_share; >> opaque record_digest<0..2^16-1>; >> opaque encrypted_sni<0..2^16-1>; >> } ClientEncryptedSNI; >> >> The service name is encrypted, but we would have to do something to no= t reveal the hash of the key in the "record digest". > This seems to highlight my main reservation about the 1-RTT approach. > I think we ought not to complicate things and just pay the round trip. My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns. As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that, the prototype can just reuse the existing code. -- Christian Huitema --------------9ED6F6931B535450FDD55751 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/27/2019 5:40 PM, Christopher Wood wrote:
On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <huitema@huitema.net> wrote:

On 2/27/2019 4:48 PM, David Schinazi wrote:

<chair hat off>
Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it.

I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest".

This seems to highlight my main reservation about the 1-RTT approach.
I think we ought not to complicate things and just pay the round trip.

My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.

As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that, the prototype can just reuse the existing code.

-- Christian Huitema


--------------9ED6F6931B535450FDD55751-- From nobody Wed Feb 27 18:04:43 2019 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 86D3B130EE0 for ; Wed, 27 Feb 2019 18:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qnjZSp7SNW_o for ; Wed, 27 Feb 2019 18:04:39 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 2CB6C130ED1 for ; Wed, 27 Feb 2019 18:04:39 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id u200so9839932ywu.10 for ; Wed, 27 Feb 2019 18:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5N7xhyYfxwr+6BdNs7x3D7mby40K+Cwueq4ielx+eaM=; b=nZPaa2D5YlBKOe5ea7oQZG4pbnLyAeS0OLy7yDjQLGDxg42FHa/0iyCjBciWFBeXAx Gwa+288qOef9n1Z3wsEOIStWrXSrtFM9BoFeFxFU+prnW5y7bMtQuPn3lHrXqapcPXxq ZEnOrHMCaEt+p+HW50pW3D2W8JCi3rWKaOBB9xT45qKCgc2pVkegnoQIQ3E0h6dGz+hD UIxun/Fad7pukCOAo6bgWK53Gx88AAVxoD7IRWR3lH9OQLQzb+b5gxUfTP9In7FpNqye qS6QBHLwiQ00rN3Cis68SQbyHwKnt7OtQTgS2buwShkpM26WEirzKmVgIvoaaqQm1dKz bSIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5N7xhyYfxwr+6BdNs7x3D7mby40K+Cwueq4ielx+eaM=; b=GWtAYCS6tGYmjVSUtMvir7Lgq7BTLO8VN+F9VvCbXAgtzS4FarCpBGHOuZiV0JPKYA tGAwahP/g2dY/tElU93rbfUQKe6Nvr7cDxDWb300nqhCyHruLqutggRJW1sWIA2JRM2A Vy3JIRCCHOnz9we5sLhtUagAnBm4Xq0qouQKekniCnk+IelvFBzjSRZksId5+sdkO000 QH79ImUBPyJl8Ldi5tobROy2LMEuZ63NJlnQzFWQCvTwf3enH5SSyHnPsrs+yqL/J83i mkjmINR/PSCYWfx6QUXOHaHHbDPIDHgidKBHurGV9yQFQzMm/YU+Im1uQExF5HechdjF rREw== X-Gm-Message-State: AHQUAua5fMs9wDfgK1eN0PCaodz3b6A/5HlwGjVBKqwj3MVesUuX7kTR AYhWTBU8BRtAlYsHAihSm4LPT+FeapJ25HbE7wk= X-Google-Smtp-Source: AHgI3IbHfDR6+eF8plj3TEoXUMnP/qVXHu19+77Ne5iyWcqop2/EpAP6ydCENH30wD0Oc5eDY/TQ1wUcrFcjlJzuMv0= X-Received: by 2002:a0d:edc3:: with SMTP id w186mr3771186ywe.301.1551319478118; Wed, 27 Feb 2019 18:04:38 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> In-Reply-To: <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> From: Christopher Wood Date: Wed, 27 Feb 2019 18:04:26 -0800 Message-ID: To: Christian Huitema Cc: Bob Bradley , DNSSD , David Schinazi Content-Type: multipart/alternative; boundary="0000000000006d2cc30582eab612" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 02:04:42 -0000 --0000000000006d2cc30582eab612 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema wrote: > > On 2/27/2019 5:40 PM, Christopher Wood wrote: > > On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <= huitema@huitema.net> wrote: > > On 2/27/2019 4:48 PM, David Schinazi wrote: > > > Given that our main target is local networks, I personally believe spendi= ng an extra round trip to prevent dictionary attacks sounds worth it. > > I am thinking of using the ESNI extension, or developing a very similar e= xtension specifically for the purpose of private discovery. The ESNI extens= ion format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-es= ni/?include_text=3D1 as: > > struct { > CipherSuite suite; > KeyShareEntry key_share; > opaque record_digest<0..2^16-1>; > opaque encrypted_sni<0..2^16-1>; > } ClientEncryptedSNI; > > The service name is encrypted, but we would have to do something to not r= eveal the hash of the key in the "record digest". > > This seems to highlight my main reservation about the 1-RTT approach. > I think we ought not to complicate things and just pay the round trip. > > My priority there is not the 1 RTT design, but rather the integration wit= h > TLS. I don't like coming up with a new crypto protocol, even when using > well known patterns. > That=E2=80=99s a fair concern. Note that I=E2=80=99m not advocating for som= ething that=E2=80=99s not TLS. I=E2=80=99m simply advocating for something that=E2=80=99s not one= stage. As for the complication, the only requirement is to omit the record_digest, > or redefine it to include a nonce. Apart from that, the prototype can jus= t > reuse the existing code. > The record digest is required to prevent downgrade attacks in the normal ESNI case. Depending on how the keys are installed, it may be fine to omit here. Can you please be specific for how you expect this optional nonce to work? It would help this discussion, I think. Thanks, Chris --0000000000006d2cc30582eab612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20


On 2/27/2019 5:40 P= M, Christopher Wood wrote:
On Wed, Feb 27, 201=
9 at 5:37 PM Christian Huitema <huite=
ma@huitema.net> wrote:

On 2/27/2019 4:48=
 PM, David Schinazi wrote:

<chair hat off>
Given that our main target is local networks, I personally believe spending=
 an extra round trip to prevent dictionary attacks sounds worth it.

I am thinking of using the ESNI extension, or developing a very similar ext=
ension specifically for the purpose of private discovery. The ESNI extensio=
n format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-=
esni/?include_text=3D1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not rev=
eal the hash of the key in the "record digest".

This seems to highl=
ight my main reservation about the 1-RTT approach.
I think we ought not to complicate things and just pay the round trip.

My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.

=

That=E2=80=99s a fair concern= . Note that I=E2=80=99m not advocating for something that=E2=80=99s not TLS= . I=E2=80=99m simply advocating for something that=E2=80=99s not one stage.=

As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that, the prototype can just reuse the existing code.


The record digest is require= d to prevent downgrade attacks in the normal ESNI case. Depending on how th= e keys are installed, it may be fine to omit here.=C2=A0

Can you please be specific for how you exp= ect this optional nonce to work? It would help this discussion, I think.

Thanks,
Chris



--0000000000006d2cc30582eab612-- From nobody Wed Feb 27 19:33:01 2019 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 4911C127598 for ; Wed, 27 Feb 2019 19:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 2-2Jd1In52ES for ; Wed, 27 Feb 2019 19:32:57 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 461C21228B7 for ; Wed, 27 Feb 2019 19:32:57 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x1S3WRuD028454; Wed, 27 Feb 2019 19:32:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=y0OFf5mockuLJ+eY6bsAKRYrTnFS1iY7ps+q5jJHV0Y=; b=GGC07VD1GTUwquOd9uR021Wa41M7tptpwy4MR1kCqUqeTYugE2zTrARAViAR91AO3x83 woLIp0/5lhm3OK4ue/0Di369oLhARbXz70BSZ/Rztv0652q67MVwXqJ7PCCJZl4nzvZc GO03wYEgbsvMnRs7m8SUeEzl94wuvpt9re0z0nyQ789CtOAYG8/Ij9VeSAbdmO43ff1G xD9b5nmnXuU4ncepMe8eYAjsSTYAm2/avrytiza1mWh5NXmDkLV0aRyRKvjuCDHBaOwz 60ibWKZNl/eE11uLC4ioRoMOfIewZbTIlyPNINWqUTH2U9n+zzBCv/5WV+PO8+rc9mi3 3Q== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2qu3r38jc5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Feb 2019 19:32:51 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bv/KmB5x7ad9itOK0xQ9fQ)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PNM007789URX8A0@ma1-mtap-s03.corp.apple.com>; Wed, 27 Feb 2019 19:32:51 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PNM004009HCSR00@nwk-mmpp-sz12.apple.com>; Wed, 27 Feb 2019 19:32:51 -0800 (PST) X-Va-A: X-Va-T-CD: ef32e8beda2f07f043a654f225792f0e X-Va-E-CD: a4bee68cb9a28f988d727c8ecff39609 X-Va-R-CD: edf26e1a2599e7fb606d76b44a391aa1 X-Va-CD: 0 X-Va-ID: dca9c05f-75e7-48c4-a973-b4a548e74407 X-V-A: X-V-T-CD: ef32e8beda2f07f043a654f225792f0e X-V-E-CD: a4bee68cb9a28f988d727c8ecff39609 X-V-R-CD: edf26e1a2599e7fb606d76b44a391aa1 X-V-CD: 0 X-V-ID: 50ff0925-acfc-4b06-a3e4-7cd3c5a51267 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-28_02:,, signatures=0 Received: from [17.234.101.71] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PNM009O49UQ4J10@nwk-mmpp-sz12.apple.com>; Wed, 27 Feb 2019 19:32:51 -0800 (PST) Sender: bradley@apple.com From: Bob Bradley Message-id: <63A34779-850D-4402-A229-16F1B07268EE@apple.com> Date: Wed, 27 Feb 2019 19:32:50 -0800 In-reply-to: Cc: Christian Huitema , DNSSD , David Schinazi To: Christopher Wood References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-28_02:, , signatures=0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 03:32:59 -0000 --Boundary_(ID_bv/KmB5x7ad9itOK0xQ9fQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Feb 27, 2019, at 6:04 PM, Christopher Wood = wrote: >=20 > On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema > wrote: >=20 >=20 > On 2/27/2019 5:40 PM, Christopher Wood wrote: >> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema = wrote: >>> On 2/27/2019 4:48 PM, David Schinazi wrote: >>>=20 >>> >>> Given that our main target is local networks, I personally believe = spending an extra round trip to prevent dictionary attacks sounds worth = it. >>>=20 >>> I am thinking of using the ESNI extension, or developing a very = similar extension specifically for the purpose of private discovery. The = ESNI extension format is defined in = https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=3D1 = = as: >>>=20 >>> struct { >>> CipherSuite suite; >>> KeyShareEntry key_share; >>> opaque record_digest<0..216-1>; >>> opaque encrypted_sni<0..216-1>; >>> } ClientEncryptedSNI; >>>=20 >>> The service name is encrypted, but we would have to do something to = not reveal the hash of the key in the "record digest". >> This seems to highlight my main reservation about the 1-RTT approach. >> I think we ought not to complicate things and just pay the round = trip. > My priority there is not the 1 RTT design, but rather the integration = with TLS. I don't like coming up with a new crypto protocol, even when = using well known patterns. >=20 >=20 > That=E2=80=99s a fair concern. Note that I=E2=80=99m not advocating = for something that=E2=80=99s not TLS. I=E2=80=99m simply advocating for = something that=E2=80=99s not one stage. I may be missing something, but the TLS/ESNI approach seems to assume = you already know the peer you want to communicate with and their IP = address to make a TLS connection. For local network communication, you = would need some earlier message exchange, such as normal mDNS to = discovery that info. The main reason for the first message (multicast probe) in my proposal = was to enable the initial discovery of peers (before any specific = queries). Since that message needed to be sent anyway, before any = unicast messages could be sent, it included an ephemeral key to also act = as the first round of key exchange (1 multicast out, N unicast in). Since I also wanted to keep the query itself confidential between the = two peers (friend A can't decrypt my queries to friend B), the sender = couldn't encrypt with its public key unless it include a separate, = encrypted query for every peer in its database (likely prohibitive). = Given those requirements, the initial multicast probe reduces the number = of messages rather than adding additional round trips. > As for the complication, the only requirement is to omit the = record_digest, or redefine it to include a nonce. Apart from that the = prototype can just reuse the existing code. >=20 >=20 > The record digest is required to prevent downgrade attacks in the = normal ESNI case. Depending on how the keys are installed, it may be = fine to omit here.=20 >=20 > Can you please be specific for how you expect this optional nonce to = work? It would help this discussion, I think. >=20 > Thanks, > Chris >=20 >=20 >=20 --Boundary_(ID_bv/KmB5x7ad9itOK0xQ9fQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
On = Feb 27, 2019, at 6:04 PM, Christopher Wood <christopherwood07@gmail.com> wrote:

On Wed, Feb 27, 2019 at 5:58 PM = Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20


On 2/27/2019 = 5:40 PM, Christopher Wood wrote:
On Wed, Feb 27, =
2019 at 5:37 PM Christian Huitema <huitema@huitema.net> wrote:

On 2/27/2019 =
4:48 PM, David Schinazi wrote:

<chair hat off>
Given that our main target is local networks, I personally believe =
spending an extra round trip to prevent dictionary attacks sounds worth =
it.

I am thinking of using the ESNI extension, or developing a very similar =
extension specifically for the purpose of private discovery. The ESNI =
extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?in=
clude_text=3D1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not =
reveal the hash of the key in the "record digest".

This seems to =
highlight my main reservation about the 1-RTT approach.
I think we ought not to complicate things and just pay the round =
trip.

My priority there is not the 1 RTT = design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known = patterns.


That=E2=80=99s a fair = concern. Note that I=E2=80=99m not advocating for something that=E2=80=99s= not TLS. I=E2=80=99m simply advocating for something that=E2=80=99s not = one stage.

I may be missing something, but the TLS/ESNI = approach seems to assume you already know the peer you want to = communicate with and their IP address to make a TLS connection. For = local network communication, you would need some earlier message = exchange, such as normal mDNS to discovery that info.

The main reason for the first message (multicast = probe) in my proposal was to enable the initial discovery of peers = (before any specific queries). Since that message needed to be sent = anyway, before any unicast messages could be sent, it included an = ephemeral key to also act as the first round of key exchange (1 = multicast out, N unicast in).

Since = I also wanted to keep the query itself confidential between the two = peers (friend A can't decrypt my queries to friend B), the sender = couldn't encrypt with its public key unless it include a separate, = encrypted query for every peer in its database (likely prohibitive). = Given those requirements, the initial multicast probe reduces the number = of messages rather than adding additional round trips.

As for the = complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that = the prototype can just reuse the existing = code.


The record digest is = required to prevent downgrade attacks in the normal ESNI case. Depending = on how the keys are installed, it may be fine to omit = here. 

Can you please be specific for how you expect = this optional nonce to work? It would help this discussion, I = think.

Thanks,
Chris




= --Boundary_(ID_bv/KmB5x7ad9itOK0xQ9fQ)-- From nobody Wed Feb 27 19:37:59 2019 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 87EC31228B7 for ; Wed, 27 Feb 2019 19:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, 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 ycizUTt6zQIb for ; Wed, 27 Feb 2019 19:37:55 -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 927991200D7 for ; Wed, 27 Feb 2019 19:37:54 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzCW7-0009rk-7L for dnssd@ietf.org; Thu, 28 Feb 2019 04:37:52 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzCVu-0002MD-7U for dnssd@ietf.org; Wed, 27 Feb 2019 22:37:42 -0500 Received: (qmail 17479 invoked from network); 28 Feb 2019 03:37:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 03:37:37 -0000 To: Christopher Wood Cc: Bob Bradley , DNSSD , David Schinazi References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> From: Christian Huitema 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: Date: Wed, 27 Feb 2019 19:37: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: Content-Type: multipart/alternative; boundary="------------671F79F6F9BDC0F42E3A589C" Content-Language: en-US X-Originating-IP: 168.144.250.223 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: ham X-Spampanel-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vL9OnC1XzLSFwdx3nB8jhF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxOnkTkhhZZhB0eCrfQ/1+s1Dj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CwBCT9sIkLmxDvdn5Y/nzU5EpHPznVavQp4h 1cyzxbRC4xvs/7iGgDKhZ45D5vihvZAdx4vjUFLh0kXGIOazxFpgLxqZUFZdwbOLffZB9SIbeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80DrsibCyBr x+YtCB8oetqRijWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SK/lIPtlUiBhTzlv5XU8Y E2iH1Wgh6RAenBR+licROGYpdSSwoNX/JQLuoQOg/Yb9zrQYrb8D2DW+FmTFNdXGYC+bZYWuu2OL SW53AXMPyanFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeB7HlN2YA3iyCV6axofC5fnozswVgmo2tH4W 8yU3FuMq4xOBkoeSzFd1sgtMF/3XfUzMKSdupn/1sw8PhB4z0FQ8CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDl1sLFxHj6kXIGqVk7wwMysWf3MLbn7l3g+Lh7r9C5nLMpdrjtWjWoVN8YHT+ snsrp0y2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 03:37:58 -0000 This is a multi-part message in MIME format. --------------671F79F6F9BDC0F42E3A589C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2019 6:04 PM, Christopher Wood wrote: > > > On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema > wrote: > > > On 2/27/2019 5:40 PM, Christopher Wood wrote: >> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema wrote: >>> On 2/27/2019 4:48 PM, David Schinazi wrote: >>> >>> >>> Given that our main target is local networks, I personally believ= e spending an extra round trip to prevent dictionary attacks sounds worth= it. >>> >>> I am thinking of using the ESNI extension, or developing a very s= imilar extension specifically for the purpose of private discovery. The E= SNI extension format is defined in https://datatracker.ietf.org/doc/draft= -ietf-tls-esni/?include_text=3D1 as: >>> >>> struct { >>> CipherSuite suite; >>> KeyShareEntry key_share; >>> opaque record_digest<0..2^^16 -1>; >>> opaque encrypted_sni<0..2^^16 -1>; >>> } ClientEncryptedSNI; >>> >>> The service name is encrypted, but we would have to do something = to not reveal the hash of the key in the "record digest". >> This seems to highlight my main reservation about the 1-RTT approa= ch. >> I think we ought not to complicate things and just pay the round t= rip. > > My priority there is not the 1 RTT design, but rather the > integration with TLS. I don't like coming up with a new crypto > protocol, even when using well known patterns. > > > That=E2=80=99s a fair concern. Note that I=E2=80=99m not advocating for= something > that=E2=80=99s not TLS. I=E2=80=99m simply advocating for something tha= t=E2=80=99s not one stage. > > As for the complication, the only requirement is to omit the > record_digest, or redefine it to include a nonce. Apart from that, > the prototype can just reuse the existing code. > > > The record digest is required to prevent downgrade attacks in the > normal ESNI case. Depending on how the keys are installed, it may be > fine to omit here.=C2=A0 > > Can you please be specific for how you expect this optional nonce to > work? It would help this discussion, I think. In the ESNI design, the digest is used to verify that the client is using the published keys and algorithms. We are concerned that DNS spoofing could enable a downgrade attack, e.g. using an old key now deemed insecure, or using the same key but with downgraded parameters. The digest protects the integrity of the transmission between DNS server and client. Since we don't plan using the DNS, we do not really have that concern. In the discussions in Bangkok, we mentioned a "hint", so servers could rapidly discard requests that are "not for me". In the old proposal, the nonce was the truncated 64 bit Unix time -- setting the 5 least significant bits to zero -- and the proof was a hash of the 7 bytes and the shared secret -- in our case, that would be the public key of the server. The nonce only changes every 30 seconds or so. Servers have to compute that proof only once every 30 seconds, which limits the potential for DOS attacks. The clients compute the nonce before sending the message. The server evaluate first whether the nonce has the right format, starts with the truncated current time plus or minus some estimate of clock drift. If that passes, the server compares to the pre-computed proof, or compute it if the clock is in a new interval. If that passes, the server processes with ESNI decryption, and verifies that the service name is what it expects. Of course, we could assume that the discovery key is passed to the peer in exactly the same format as ESNI: struct { uint8 checksum[4]; KeyShareEntry keys<4..2^16-1>; CipherSuite cipher_suites<2..2^16-2>; uint16 padded_length; uint64 not_before; uint64 not_after; Extension extensions<0..2^16-1>; } ESNIKeys; Hashing that with the nonce will alleviate concerns about clients using the wrong cipher suite, or the wrong padding length. -- Christian Huitema --------------671F79F6F9BDC0F42E3A589C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/27/2019 6:04 PM, Christopher Wood wrote:


On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <huitema@huitema.net> wrote:


On 2/27/2019 5:40 PM, Christopher Wood wrote:
On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <huitema@huitema.net> wrote:

On 2/27/2019 4:48 PM, David Schinazi wrote:

<chair hat off>
Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it.

I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest".

This seems to highlight my main reservation about the 1-RTT approach.
I think we ought not to complicate things and just pay the round trip.

My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.


That’s a fair concern. Note that I’m not advocating for something that’s not TLS. I’m simply advocating for something that’s not one stage.

As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that, the prototype can just reuse the existing code.


The record digest is required to prevent downgrade attacks in the normal ESNI case. Depending on how the keys are installed, it may be fine to omit here. 

Can you please be specific for how you expect this optional nonce to work? It would help this discussion, I think.

In the ESNI design, the digest is used to verify that the client is using the published keys and algorithms. We are concerned that DNS spoofing could enable a downgrade attack, e.g. using an old key now deemed insecure, or using the same key but with downgraded parameters. The digest protects the integrity of the transmission between DNS server and client. Since we don't plan using the DNS, we do not really have that concern.

In the discussions in Bangkok, we mentioned a "hint", so servers could rapidly discard requests that are "not for me". In the old proposal, the nonce was the truncated 64 bit Unix time -- setting the 5 least significant bits to zero -- and the proof was a hash of the 7 bytes and the shared secret -- in our case, that would be the public key of the server. The nonce only changes every 30 seconds or so. Servers have to compute that proof only once every 30 seconds, which limits the potential for DOS attacks.

The clients compute the nonce before sending the message. The server evaluate first whether the nonce has the right format, starts with the truncated current time plus or minus some estimate of clock drift. If that passes, the server compares to the pre-computed proof, or compute it if the clock is in a new interval. If that passes, the server processes with ESNI decryption, and verifies that the service name is what it expects.

Of course, we could assume that the discovery key is passed to the peer in exactly the same format as ESNI:

    struct {
        uint8 checksum[4];
        KeyShareEntry keys<4..2^16-1>;
        CipherSuite cipher_suites<2..2^16-2>;
        uint16 padded_length;
        uint64 not_before;
        uint64 not_after;
        Extension extensions<0..2^16-1>;
    } ESNIKeys;

Hashing that with the nonce will alleviate concerns about clients using the wrong cipher suite, or the wrong padding length.

-- Christian Huitema




--------------671F79F6F9BDC0F42E3A589C-- From nobody Wed Feb 27 20:15:47 2019 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 E473A12950A for ; Wed, 27 Feb 2019 20:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IgsrPzA6zP17 for ; Wed, 27 Feb 2019 20:15:43 -0800 (PST) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 6247A1274D0 for ; Wed, 27 Feb 2019 20:15:43 -0800 (PST) Received: by mail-yw1-xc33.google.com with SMTP id i204so7539754ywb.0 for ; Wed, 27 Feb 2019 20:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DInFz0PxbMHFZmw4HQHU/bjtR7RCNg2FPJX1MxARNtI=; b=EElbHGNf3YCkgqk5o4rkEdJXSegUQ6cXIWaE0+aDQYu2b7+M0Hv7sOY3+3wRR7C93v CnQZtAZmIaer11ty3SUp/GqkpmTWR2sL+dKm4mwOnevhbWqfIrMm6hXLHfOKLbtN7J1G SSGkC0OCe1fzxOWjm7k2TFMGh0dqHg2zAP341slYiTuCfuWRlWzucNij0u7HkzZ7GvWi D6ai4PwcY50knyJ3RJrENw57M/1kuN0y+tqh2sKsvtGZjyPgRD9Trq63oLWP9ijzcAg4 y+9vpRm1T81+xaMzyq33XgxsHEDSfXpZ+4qwnYHjv+5cgLN7E6vCxyd7XLlrcb9KTcQS rLiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DInFz0PxbMHFZmw4HQHU/bjtR7RCNg2FPJX1MxARNtI=; b=i346EjuQi6HCDzFmtWzPmsv2kBhqthEnorsDr6kgua29a+HfnARDBpdadIN0ymgtWE sVjr4eE4sL5XbYLagTMouMaR4KYEtcw5OyXaAAeYF9mNQXO5CdjrCk5NxrJq7QMmpVYP +VvK8XOWqXEkNm6Co7BJvh75TC9/z3ZNt5yXKEEDNK4D5oDdUfvUrAll5E0rZAc2Wb9P rk8xkCFq4K1rdz8VqYoUaOQd6zyOjdxqeRxYMPTisFuPw5/Q/2Zerfr0S8MJLjbLLdWV jn5cLVQlodHfyuZIPY8RpnlkiEAJgOmPnr9RXD4PdhzR4Hvo/P86gUkuLXXvKNyzOwZ4 9WZg== X-Gm-Message-State: AHQUAuZ0UqmQJnko6RH/NPAaD/CDnlqIbILKsRv4OkibONYuXqLprWz2 3yDpmGSqyn8WhPEGLC5/P6afry0ZcPYm3JcSLTY= X-Google-Smtp-Source: AHgI3IbPn5KKE66mEgZhyOWcgooIG2eQszLVpuisYPyrPxIRk8IsvDyuhJ/3Ty1j4p6r4NQLn1DF+4YnrlueNgzQfcQ= X-Received: by 2002:a81:49d4:: with SMTP id w203mr3962394ywa.208.1551327342463; Wed, 27 Feb 2019 20:15:42 -0800 (PST) MIME-Version: 1.0 References: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 20:15:31 -0800 Message-ID: To: Christian Huitema Cc: Bob Bradley , DNSSD , David Schinazi Content-Type: multipart/alternative; boundary="0000000000002d90de0582ec8b82" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 04:15:46 -0000 --0000000000002d90de0582ec8b82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2019 at 7:37 PM Christian Huitema wrote: > > On 2/27/2019 6:04 PM, Christopher Wood wrote: > > > > On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema > wrote: > >> >> On 2/27/2019 5:40 PM, Christopher Wood wrote: >> >> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema = wrote: >> >> On 2/27/2019 4:48 PM, David Schinazi wrote: >> >> >> Given that our main target is local networks, I personally believe spend= ing an extra round trip to prevent dictionary attacks sounds worth it. >> >> I am thinking of using the ESNI extension, or developing a very similar = extension specifically for the purpose of private discovery. The ESNI exten= sion format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-e= sni/?include_text=3D1 as: >> >> struct { >> CipherSuite suite; >> KeyShareEntry key_share; >> opaque record_digest<0..2^16-1>; >> opaque encrypted_sni<0..2^16-1>; >> } ClientEncryptedSNI; >> >> The service name is encrypted, but we would have to do something to not = reveal the hash of the key in the "record digest". >> >> This seems to highlight my main reservation about the 1-RTT approach. >> I think we ought not to complicate things and just pay the round trip. >> >> My priority there is not the 1 RTT design, but rather the integration >> with TLS. I don't like coming up with a new crypto protocol, even when >> using well known patterns. >> > > That=E2=80=99s a fair concern. Note that I=E2=80=99m not advocating for s= omething that=E2=80=99s > not TLS. I=E2=80=99m simply advocating for something that=E2=80=99s not o= ne stage. > > As for the complication, the only requirement is to omit the >> record_digest, or redefine it to include a nonce. Apart from that, the >> prototype can just reuse the existing code. >> > > The record digest is required to prevent downgrade attacks in the normal > ESNI case. Depending on how the keys are installed, it may be fine to omi= t > here. > > Can you please be specific for how you expect this optional nonce to work= ? > It would help this discussion, I think. > > In the ESNI design, the digest is used to verify that the client is using > the published keys and algorithms. We are concerned that DNS spoofing cou= ld > enable a downgrade attack, e.g. using an old key now deemed insecure, or > using the same key but with downgraded parameters. The digest protects th= e > integrity of the transmission between DNS server and client. Since we don= 't > plan using the DNS, we do not really have that concern. > > In the discussions in Bangkok, we mentioned a "hint", so servers could > rapidly discard requests that are "not for me". In the old proposal, the > nonce was the truncated 64 bit Unix time -- setting the 5 least significa= nt > bits to zero -- and the proof was a hash of the 7 bytes and the shared > secret -- in our case, that would be the public key of the server. The > nonce only changes every 30 seconds or so. Servers have to compute that > proof only once every 30 seconds, which limits the potential for DOS > attacks. > > The clients compute the nonce before sending the message. The server > evaluate first whether the nonce has the right format, starts with the > truncated current time plus or minus some estimate of clock drift. If tha= t > passes, the server compares to the pre-computed proof, or compute it if t= he > clock is in a new interval. If that passes, the server processes with ESN= I > decryption, and verifies that the service name is what it expects. > > Of course, we could assume that the discovery key is passed to the peer i= n > exactly the same format as ESNI: > > struct { > uint8 checksum[4]; > KeyShareEntry keys<4..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > uint16 padded_length; > uint64 not_before; > uint64 not_after; > Extension extensions<0..2^16-1>; > } ESNIKeys; > > Hashing that with the nonce will alleviate concerns about clients using > the wrong cipher suite, or the wrong padding length. > Okay, so, as I suspected, this is vulnerable to dictionary attacks if the public key is leaked. Am I misunderstanding? If so, can you explain why this is not the case? Thanks, Chris --Christian Huitema > > > > > --0000000000002d90de0582ec8b82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 27, 2019 at 7:37 PM Chris= tian Huitema <huitema@huitema.net= > wrote:
=20 =20 =20


On 2/27/2019 6:04 = PM, Christopher Wood wrote:
=20


On Wed, Feb 27, 2019 at 5:5= 8 PM Christian Huitema <huitema@huitema.net> wrote:


On 2/27/2019 5:40 PM, Christopher Wood wrote:
On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <huitema@huitema.net> wrote:

On 2/27/2019 4:48 PM, David Schinazi wrote:

<chair hat off>
Given that our main target is local networks, I personally believe spending=
 an extra round trip to prevent dictionary attacks sounds worth it.

I am thinking of using the ESNI extension, or developing a very similar ext=
ension specifically for the purpose of private discovery. The ESNI extensio=
n format is defined in https://datatracker.ietf.o=
rg/doc/draft-ietf-tls-esni/?include_text=3D1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not rev=
eal the hash of the key in the "record digest".

This seems to highlight my main reservation about the 1-RTT ap=
proach.
I think we ought not to complicate things and just pay the round trip.

My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.


That=E2=80=99s a fair concern. Note that I=E2= =80=99m not advocating for something that=E2=80=99s not TLS. I=E2=80=99m si= mply advocating for something that=E2=80=99s not one stage.

As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that, the prototype can just reuse the existing code.


The record digest is required to prevent downgrade attacks in the normal ESNI case. Depending on how the keys are installed, it may be fine to omit here.=C2=A0

Can you please be specific for how you expect this optional nonce to work? It would help this discussion, I think.

In the ESNI design, the digest is used to verify that the client is using the published keys and algorithms. We are concerned that DNS spoofing could enable a downgrade attack, e.g. using an old key now deemed insecure, or using the same key but with downgraded parameters. The digest protects the integrity of the transmission between DNS server and client. Since we don't plan using the DNS, we do not really have that concern.

In the discussions in Bangkok, we mentioned a "hint", so s= ervers could rapidly discard requests that are "not for me". In th= e old proposal, the nonce was the truncated 64 bit Unix time -- setting the 5 least significant bits to zero -- and the proof was a hash of the 7 bytes and the shared secret -- in our case, that would be the public key of the server. The nonce only changes every 30 seconds or so. Servers have to compute that proof only once every 30 seconds, which limits the potential for DOS attacks.

The clients compute the nonce before sending the message. The server evaluate first whether the nonce has the right format, starts with the truncated current time plus or minus some estimate of clock drift. If that passes, the server compares to the pre-computed proof, or compute it if the clock is in a new interval. If that passes, the server processes with ESNI decryption, and verifies that the service name is what it expects.

Of course, we could assume that the discovery key is passed to the peer in exactly the same format as ESNI:

    struct {
        uint8 checksum[4];
        KeyShareEntry keys<4..2^16-1>;
        CipherSuite cipher_suites<2..2^16-2>;
        uint16 padded_length;
        uint64 not_before;
        uint64 not_after;
        Extension extensions<0..2^16-1>;
    } ESNIKeys;

Hashing that with the nonce will alleviate concerns about clients using the wrong cipher suite, or the wrong padding length.

<= /blockquote>

Okay, so, as I su= spected, this is vulnerable to dictionary attacks if the public key is leak= ed. Am I misunderstanding? If so, can you explain why this is not the case?=

Thanks,
Chris=C2=A0

--Christian Huitema




--0000000000002d90de0582ec8b82-- From nobody Wed Feb 27 21:43:49 2019 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 6B581128701 for ; Wed, 27 Feb 2019 21:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i47iwwSCPH3y for ; Wed, 27 Feb 2019 21:43:45 -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 796401274D0 for ; Wed, 27 Feb 2019 21:43:45 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzETu-0004On-Ry for dnssd@ietf.org; Thu, 28 Feb 2019 06:43:43 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzETr-0004wh-Ti for dnssd@ietf.org; Thu, 28 Feb 2019 00:43:40 -0500 Received: (qmail 22166 invoked from network); 28 Feb 2019 05:43:38 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 05:43:38 -0000 To: Christopher Wood Cc: David Schinazi , DNSSD , Bob Bradley References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> From: Christian Huitema 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: Date: Wed, 27 Feb 2019 21:43: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.223 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.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tCdsyEbTjUO6gTZnHuXI2B602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxDmn2sdo3WN+1Z9aUit6++lDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl9semLNqCiyb McRB+7cwn45qJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+XZn+jfiXlyx/4w3cIP7HIiDg5/bq7ChmPMN Ycw1QSmRXGem+cIl4bnIFIySUDHqnAVhL6EU6GsBdd1k4MewJndm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhig9BN5xox//guz4J7hZbfQO+NTKQHNkjJg8xvPcdYB8Xah1yKErL337gnQ6s FmyUdf27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 05:43:48 -0000 On 2/27/2019 8:15 PM, Christopher Wood wrote: > Okay, so, as I suspected, this is vulnerable to dictionary attacks if > the public key is leaked. Am I misunderstanding? If so, can you > explain why this is not the case? If the public key is leaked, anyone with the leaked key can impersonate an authorized client, establish a connection, etc. The secrecy of the public key is what keeps this together. In all these schemes, there has to be a secret that acts as the seed for the privates exchanges, and in the scheme I propose that secret is the public discovery key of the server. -- Christian Huitema From nobody Wed Feb 27 22:25:18 2019 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 D8D63129508 for ; Wed, 27 Feb 2019 22:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IVZdvLdIRsXk for ; Wed, 27 Feb 2019 22:25:16 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 6C9D9128701 for ; Wed, 27 Feb 2019 22:25:16 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id q128so10200788ywg.8 for ; Wed, 27 Feb 2019 22:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Su8tFU8F5JubR1DEE7JWHFzgmJ1tjeDnoCIdaAYs/k=; b=JQvemvsy/OP5OLiRO+T7vLDnD4NDEeAnsPZq/tm13zxlKFTkmf+pHLNTZ0Mnnn8aaP T1tgy5ORpz9NiZfNC1IZHmF7xCzo4yrDe06AdWcyfp/jYBqbM8mTMfCC5ffnPdGM3+Lc KTRdb+NpsA9G+EchKolWvz8WJq3mFVpI83OxMxIy456Lxxfa+aG1/abYfEfAZNCJRdMh Rlx5XN0Ao8WZCUFfNyGNIRr5889TlQpjfgdyTfRYBebvWjjgySxWQ5uxc31vwPsAdIJV OZ/FLeohcvotHyWul3Bwt3LO7Xq03jWcUNAwCovm5u3RlefGessa7sCswsdFzR4lVVLt W8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+Su8tFU8F5JubR1DEE7JWHFzgmJ1tjeDnoCIdaAYs/k=; b=ARH9AVan19wh6BlYKDHKJQ0uTNfBVbpdwIEzPpnNE2zG9JMeOUWjl6xb53mdwwXfOd xKK4/5XIkUciWrwhhDqVBc1qBMfxElyBp0bTKD2MqH3hLYndkEhlNVxJ0gYqxZxA7Awv miMLxYwBSmtmhg6azMrFmhZ8L0xBLFiCLzTPcSQdMJuCxI1fCoofFIn8v04F++2AoMY+ ljFNGBUabKSE6DMkv9u8xAbsS9iwHSt2ERyk2i3uwwr93XpPNFz6Xf+eHvpU5jwLV0ZY LkTIJQC+ANgPg3TIGrvgUfxiLySYYmoaAyv1wCNvFSne6/FfNeQok9YDKPLt3/vH+TWi RTbQ== X-Gm-Message-State: AHQUAuaslhkzPq5fwQMWetEP9E3PzIjgVSVlaMFSY/fYHjTmi2X7qPAl wpCb5jvFYLhXf4c1OuxmP7c2qhrnpXNq9ClpzdI= X-Google-Smtp-Source: AHgI3IaG/NhGzA1W27jJyZGfKxyGWnhFbvS5XWonV2Wdbv4TxT8IquR9CAvfrJW8I+JfobfxJxWNoqzg07hPyrSnFB0= X-Received: by 2002:a0d:ec08:: with SMTP id v8mr4358662ywe.298.1551335115283; Wed, 27 Feb 2019 22:25:15 -0800 (PST) MIME-Version: 1.0 References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 22:25:04 -0800 Message-ID: To: Christian Huitema Cc: Bob Bradley , DNSSD , David Schinazi Content-Type: multipart/alternative; boundary="00000000000079614f0582ee5af6" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 06:25:18 -0000 --00000000000079614f0582ee5af6 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema wrote: > On 2/27/2019 8:15 PM, Christopher Wood wrote: > > > Okay, so, as I suspected, this is vulnerable to dictionary attacks if > > the public key is leaked. Am I misunderstanding? If so, can you > > explain why this is not the case? > > If the public key is leaked, anyone with the leaked key can impersonate > an authorized client, establish a connection, etc. The secrecy of the > public key is what keeps this together. In all these schemes, there has > to be a secret that acts as the seed for the privates exchanges, and in > the scheme I propose that secret is the public discovery key of the server. Right! That confirms what I said above. Thanks for clarifying. > --00000000000079614f0582ee5af6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema <huitema@huitema.net> wrote:
On 2/27/2019 8:15 PM, Christopher Wood wr= ote:

> Okay, so, as I suspected, this is vulnerable to dictionary attacks if<= br> > the public key is leaked. Am I misunderstanding? If so, can you
> explain why this is not the case?

If the public key is leaked, anyone with the leaked key can impersonate
an authorized client, establish a connection, etc. The secrecy of the
public key is what keeps this together. In all these schemes, there has
to be a secret that acts as the seed for the privates exchanges, and in
the scheme I propose that secret is the public discovery key of the server.=

Right! That conf= irms what I said above. Thanks for clarifying.=C2=A0
--00000000000079614f0582ee5af6-- From nobody Thu Feb 28 06:28:58 2019 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 A2932130E91 for ; Thu, 28 Feb 2019 06:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aqjRQIrHFZmw for ; Thu, 28 Feb 2019 06:28:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05C7130E9C for ; Thu, 28 Feb 2019 06:28:54 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 82AB33826A; Thu, 28 Feb 2019 09:28:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3BE29D63; Thu, 28 Feb 2019 09:28:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3A5D25D; Thu, 28 Feb 2019 09:28:53 -0500 (EST) From: Michael Richardson To: Christian Huitema CC: dnssd@ietf.org In-Reply-To: References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 14:28:57 -0000 --=-=-= Content-Type: text/plain Christian Huitema wrote: >> Okay, so, as I suspected, this is vulnerable to dictionary attacks if >> the public key is leaked. Am I misunderstanding? If so, can you >> explain why this is not the case? > If the public key is leaked, anyone with the leaked key can impersonate > an authorized client, establish a connection, etc. The secrecy of the > public key is what keeps this together. In all these schemes, there has > to be a secret that acts as the seed for the privates exchanges, and in > the scheme I propose that secret is the public discovery key of the server. Since we have extensive public training that the "public key" is safe to disclose, this may be confusing for many, as this is no longer the case for this. May I suggest different terminology? As the two halves of asymmetric keying systems are mathematically equivalent, so maybe we could call it the client-dual-key or something like that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlx38CQACgkQgItw+93Q 3WUFRAf/c2GZaB2dxjf4aHJd3+hhg1WKSRe4K7BK+Ovin/Ul712q/gMKyHQe4eDb UQCUl6zC+7SYRcsq6wmbxEkCkfMv/WdmSAB+iOSlyOjg7z9NWJxU0avig4VoNnlw kpEmmvrGxQEAaMZ45zIOWHvyQcvhU1tL1AXGx7/FXcUWbZt8KJWCSpTbAkdLZw6F pP2KDNbjrbF1uXowmDHe5PoLyQVLMZsqljAL7H/GQ/Fq02d1Fv9XoesnTW5w/qHV Hf1Umtw4xbpRIMFnsQofBGUiBLNiT0s2mQG0HSqCcCpks+ZsBAMASf7gi9VtQKpZ vt7BBm6mPhshiUc9ZpAYDvrLj6miFQ== =0IBx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 28 10:03:29 2019 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 381FD130EE9 for ; Thu, 28 Feb 2019 10:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, 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 pVDJKRK1Y-8W for ; Thu, 28 Feb 2019 10:03:24 -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 6F1BC130EE5 for ; Thu, 28 Feb 2019 10:03:24 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzQ1h-0006Ez-2d for dnssd@ietf.org; Thu, 28 Feb 2019 19:03:22 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzQ1b-0004va-KB for dnssd@ietf.org; Thu, 28 Feb 2019 13:03:19 -0500 Received: (qmail 10925 invoked from network); 28 Feb 2019 18:03:14 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 18:03:14 -0000 To: Christopher Wood Cc: David Schinazi , DNSSD , Bob Bradley References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> From: Christian Huitema 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: Date: Thu, 28 Feb 2019 10:03:14 -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: Content-Type: multipart/alternative; boundary="------------47348BFCAEA0ABB41E8D60EE" Content-Language: en-US X-Originating-IP: 168.144.250.230 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.24) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nn2Bjpd10CoJQv82/gGNWd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxhKK7dh6UhBNy9xseh6b8vFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j52UOCQU2jyl+0Kabky0HVIE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMTc/0DL0kGticgfK7BXdIl5xnsMi381k+gKZDYa33nZ/SLYX401Mu2y PxH9aQ/+aT5k354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxteZCbtAjVCK4+cnZ2w0Gj7pzZ37L30ZhGNgpmh3vaNC1Qhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:03:26 -0000 This is a multi-part message in MIME format. --------------47348BFCAEA0ABB41E8D60EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/27/2019 10:25 PM, Christopher Wood wrote: > > > On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema > wrote: > > On 2/27/2019 8:15 PM, Christopher Wood wrote: > > > Okay, so, as I suspected, this is vulnerable to dictionary > attacks if > > the public key is leaked. Am I misunderstanding? If so, can you > > explain why this is not the case? > > If the public key is leaked, anyone with the leaked key can > impersonate > an authorized client, establish a connection, etc. The secrecy of t= he > public key is what keeps this together. In all these schemes, > there has > to be a secret that acts as the seed for the privates exchanges, > and in > the scheme I propose that secret is the public discovery key of > the server. > > > Right! That confirms what I said above. Thanks for clarifying. And thanks for clarifying the dictionary attack concern. I was blinded by the "all bets are off" assumption. If the discovery key of the service is known by attackers, then the attackers can detect the presence of the service in a local network. They indeed can, but all bets are not off. The attackers have to mount an active attack. They have to attempt a discovery and see whether the service is present and replies. If we use hints, they can perform a passive dictionary attack, e.g. browsing logs of traffic and detecting whether the service was present. The all bets are off assumption is wrong, we have to think of defense in depth. Bottom line, the ESNI based solution should use a static proforma "record_digest", or no record digest at all. No hints, just use trial decryption, like Bob proposed. If we become concerned about the cost of trial decryption, we can start playing with time windows. Many scenarios have a "meeting" structure, "A meets B and they discover each other". We can arrange mitigations around that, e.g. only perform trial decryption when the app is actively waiting for connections. -- Christian Huitema --------------47348BFCAEA0ABB41E8D60EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/27/2019 10:25 PM, Christopher Wood wrote:


On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema <huitema@huitema.net> wrote:
On 2/27/2019 8:15 PM, Christopher Wood wrote:

> Okay, so, as I suspected, this is vulnerable to dictionary attacks if
> the public key is leaked. Am I misunderstanding? If so, can you
> explain why this is not the case?

If the public key is leaked, anyone with the leaked key can impersonate
an authorized client, establish a connection, etc. The secrecy of the
public key is what keeps this together. In all these schemes, there has
to be a secret that acts as the seed for the privates exchanges, and in
the scheme I propose that secret is the public discovery key of the server.

Right! That confirms what I said above. Thanks for clarifying.

And thanks for clarifying the dictionary attack concern. I was blinded by the "all bets are off" assumption. If the discovery key of the service is known by attackers, then the attackers can detect the presence of the service in a local network. They indeed can, but all bets are not off. The attackers have to mount an active attack. They have to attempt a discovery and see whether the service is present and replies. If we use hints, they can perform a passive dictionary attack, e.g. browsing logs of traffic and detecting whether the service was present. The all bets are off assumption is wrong, we have to think of defense in depth.

Bottom line, the ESNI based solution should use a static proforma "record_digest", or no record digest at all. No hints, just use trial decryption, like Bob proposed.

If we become concerned about the cost of trial decryption, we can start playing with time windows. Many scenarios have a "meeting" structure, "A meets B and they discover each other". We can arrange mitigations around that, e.g. only perform trial decryption when the app is actively waiting for connections.

-- Christian Huitema

--------------47348BFCAEA0ABB41E8D60EE-- From nobody Thu Feb 28 10:05:45 2019 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 193FC130EFE for ; Thu, 28 Feb 2019 10:05:44 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 oab1Da2zqpeF for ; Thu, 28 Feb 2019 10:05:42 -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 37045130EE5 for ; Thu, 28 Feb 2019 10:05:42 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzQ3u-0006Sy-N0 for dnssd@ietf.org; Thu, 28 Feb 2019 19:05:39 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzQ3n-0007tC-9J for dnssd@ietf.org; Thu, 28 Feb 2019 13:05:35 -0500 Received: (qmail 14771 invoked from network); 28 Feb 2019 18:05:29 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 18:05:29 -0000 To: Michael Richardson Cc: dnssd@ietf.org References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <5847.1551364133@localhost> From: Christian Huitema 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: Date: Thu, 28 Feb 2019 10:05:19 -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: <5847.1551364133@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mj3RRohgAggEyNtWYFXKOjK7BxGW7aG5W" X-Originating-IP: 168.144.250.232 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.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5n92O72STpaboab6iA98wCV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax9E8sPTdWcAQfTc/0m3/WTVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5DyjP96uQ2jXbVpuo3IrHok5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMT6pROnyAKITGlzFOYjpZTisSA7ZA+Sy9kbvpgxW3TeNUXYhVx2tcNo 23fge31rMopqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+elpXlXsYEKiOTsiESb6idaDg5/bq7ChmPMN Ycw1QSmR3IhlH4AwXeeLlOdxXEwFPmyaq4bTJGRvEOrflDYLro9m4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiimxcJ9s1w9uxbJROTdpUdu+NTKQHNkjJg8xvPcdYB8X9H4DectLaqn7kLkt Zo9lq/27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:05:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mj3RRohgAggEyNtWYFXKOjK7BxGW7aG5W Content-Type: multipart/mixed; boundary="p15leEgPE4goKEjoDSwIkDZxI89VAiBgf"; protected-headers="v1" From: Christian Huitema To: Michael Richardson Cc: dnssd@ietf.org Message-ID: Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <5847.1551364133@localhost> In-Reply-To: <5847.1551364133@localhost> --p15leEgPE4goKEjoDSwIkDZxI89VAiBgf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2/28/2019 6:28 AM, Michael Richardson wrote: > Christian Huitema wrote: > >> Okay, so, as I suspected, this is vulnerable to dictionary attac= ks if > >> the public key is leaked. Am I misunderstanding? If so, can you > >> explain why this is not the case? > > > If the public key is leaked, anyone with the leaked key can imper= sonate > > an authorized client, establish a connection, etc. The secrecy of= the > > public key is what keeps this together. In all these schemes, the= re has > > to be a secret that acts as the seed for the privates exchanges, = and in > > the scheme I propose that secret is the public discovery key of t= he server. > > Since we have extensive public training that the "public key" is safe t= o > disclose, this may be confusing for many, as this is no longer the case= for this. > > May I suggest different terminology? As the two halves of asymmetric k= eying > systems are mathematically equivalent, so maybe we could call it the > client-dual-key or something like that. It is a server key, not a client key, but I see the issue. I was thinking of using "discovery key". Would that work? -- Christian Huitema --p15leEgPE4goKEjoDSwIkDZxI89VAiBgf-- --Mj3RRohgAggEyNtWYFXKOjK7BxGW7aG5W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJceCLqAAoJELba05IUOHVQKMgH/1DUDHf4Pp1jwjyqTX38KF1g Cx7GOMVd7wVXR9JNsMuPMSXW7tBITwLCT4+64Z3H33iM9AfZPqemYhuUMSt+S0oJ gwHgUR/KAq3othwocT/nKKP0drCflTPFsYy4vxTScwK1IHh7Al0a6fGfC6OtJLEM siHeUJ/2EX2bxOAjRMcOkD2K0AhJqSq4G+gixB16no2sq2BpQVxi9P2uP1LE2nOS +YP7xlJLKh4IKaemcCiV7mXv/gcWYgETkhKMFGD9HJVf8hlWXtWCnxb3SL46zeUr BzIJmqS1flOQbc5M0ohmVOv6LxlG5IQEtw9+2R9pYSVohGZ87VhFKX1vviwMxB0= =q61y -----END PGP SIGNATURE----- --Mj3RRohgAggEyNtWYFXKOjK7BxGW7aG5W-- From nobody Thu Feb 28 14:34:29 2019 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 2DF10131053 for ; Thu, 28 Feb 2019 14:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=G8VTiY0/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XfNqKGKm 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 Um6Ln-jz8e5K for ; Thu, 28 Feb 2019 14:34:24 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC1E13104E for ; Thu, 28 Feb 2019 14:34:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2DFE0231A2 for ; Thu, 28 Feb 2019 17:34:23 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 28 Feb 2019 17:34:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=x9gVYMBHrW9iOXPWuMjFeOtgQ+8nT2TlTb7LCpo 2+6s=; b=G8VTiY0/vP9gF0uI6YQKXbkTegfCcRTYeSzVp2SJhqgAI3zCo1CbME9 Q8metN3g7DRQ+sCzeiKBt4Eq4MwW2dh88hmBrrl522QeRGwxhzZneIrr5ko9FRTP d+1kO52MX8LbKVOxnMY9tWuF3zBofOeztxO8qkVX+qx8/R7fz8iNEhF79T/h6Ikz qQD45yNHCeH8BCtjO9RL4p0ZWv7W/xntudeuLftV29CKUS7KjJpkbyKY7Iq1UKY7 qK6nLAQlMXxP83jwfIn7yAG9OGisgIGfbqSC2go5k46Zy0sezYuk+Dlv+UJyGEpg sbGWkKESL843E0RF2w2OhQoi6WFBDEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=x9gVYMBHrW9iOXPWu MjFeOtgQ+8nT2TlTb7LCpo2+6s=; b=XfNqKGKmimC6IQJmgI1PP/WMJSv4D0Vna Bq4w1U3LlACXcFqip1o0qoJjbRrIOfhvSsSS+Npx2WX9aUv96vXVy8nh/keBPC1y ti4g8NMGmxR6j4l0/xx+jCL/NEl29UFdQhuDXtfMyveIsy8zHPVvbbi4Cu1z0V8K YL1lHflP2tCB3zzipG4avCdS5MVrBFba3X/N+G+s4v6P0MbHk9/5tMhYYW4j0tFL 4p2YIhOAMRs7/3qG5lzQnnf04dkDdCzrGvJAfl3CIRaFBLeABV9rOXNizINua1j2 ghRYrIAqcqA9j9L8lEwKjGie/okdwTDwRMCekA4qKhiV9HZhghRYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdefgdduieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8A2F7C1EB; Thu, 28 Feb 2019 17:34:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 92534000 Message-Id: <30e6aaa1-4e45-46d2-b2a2-89ece41ce414@www.fastmail.com> In-Reply-To: References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <5847.1551364133@localhost> Date: Thu, 28 Feb 2019 17:34:25 -0500 From: "Martin Thomson" To: dnssd@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dnssd] =?utf-8?q?Confirming_consensus_from_DNSSD_Privacy_discus?= =?utf-8?q?sion_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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 22:34:27 -0000 I probably don't have all the context, but when I start hearing about keeping public keys secret, I always think "why not a PSK?" Is there a reason that wouldn't work here also? A PSK ensures that only those who have the key can see that the query is for an entity with the PSK. You could use DH as well to make the details of the query confidential from those as well. You don't get authentication unless you also have an asymmetric key, but that's easily doable (with TLS anyway). On Fri, Mar 1, 2019, at 05:05, Christian Huitema wrote: > > On 2/28/2019 6:28 AM, Michael Richardson wrote: > > Christian Huitema wrote: > > >> Okay, so, as I suspected, this is vulnerable to dictionary attacks if > > >> the public key is leaked. Am I misunderstanding? If so, can you > > >> explain why this is not the case? > > > > > If the public key is leaked, anyone with the leaked key can impersonate > > > an authorized client, establish a connection, etc. The secrecy of the > > > public key is what keeps this together. In all these schemes, there has > > > to be a secret that acts as the seed for the privates exchanges, and in > > > the scheme I propose that secret is the public discovery key of the server. > > > > Since we have extensive public training that the "public key" is safe to > > disclose, this may be confusing for many, as this is no longer the case for this. > > > > May I suggest different terminology? As the two halves of asymmetric keying > > systems are mathematically equivalent, so maybe we could call it the > > client-dual-key or something like that. > > It is a server key, not a client key, but I see the issue. I was > thinking of using "discovery key". Would that work? > > -- Christian Huitema > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > Attachments: > * signature.asc From nobody Thu Feb 28 15:04:12 2019 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 EA2A7130F1C for ; Thu, 28 Feb 2019 15:04:09 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 IRLU2jVA50wd for ; Thu, 28 Feb 2019 15:04:07 -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 18B81130E96 for ; Thu, 28 Feb 2019 15:04:07 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx147.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gzUif-0006Lw-NB for dnssd@ietf.org; Fri, 01 Mar 2019 00:04:04 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gzUiX-0005Zj-5w for dnssd@ietf.org; Thu, 28 Feb 2019 18:03:57 -0500 Received: (qmail 14946 invoked from network); 28 Feb 2019 23:03:49 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2019 23:03:49 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: <30e6aaa1-4e45-46d2-b2a2-89ece41ce414@www.fastmail.com> Date: Thu, 28 Feb 2019 15:03:47 -0800 Cc: dnssd@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <406056C2-CED1-4877-AD44-CF630937F787@huitema.net> References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <5847.1551364133@localhost> <30e6aaa1-4e45-46d2-b2a2-89ece41ce414@www.fastmail.com> To: Martin Thomson X-Originating-IP: 168.144.250.231 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.35) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sIMv7Zf5qcoWOOOH0DD+fR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxYcdtF9Fsy1e8rNirX3rQglDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kB7L9qFZEB58fINh4BP9MqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezYBFjKYeYprI6D9W+xTY9pPwUimsNGvJJilSn4u6QSZCRqzLn7viWp y4ASDnGTWMMs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53g/1RxwT9/iBE7K7b9LlmTrAMgFPp7+h3kLe NmBV53UGh11yCpOXhJ0kOoLblmK8rWozXRXcmpE9wVzMNpY5b/RRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/HtFe6KPzyYGlUQCNd2pMbL7G3ch6MdB0XuALpEgtIRS0LLV0L53ylJMDui2 2KlE/N40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 23:04:10 -0000 PSK would indeed work, but it is subject to very bad failure modes. If the P= SK is compromised, the attackers can not only track clients and servers, but= also impersonate servers. What would be workable is to treat the PSK ID as a discovery ticket, carryin= g the client discovery key share. The PSK would be derived from the discover= y secret. We would probably need to add a proof in the PSK ID, so broadcast r= eceivers could quickly decide that this is "not for me". In this design, the service name would not be transmitted at all. No SNI, no= ESNI. The handshake key and session key would depend on the PSK, which prov= ides all kinds of guarantees. If forward secrecy is required, use PSK + ECDH= . Structuring the PSK-ID seems ugly, but we do that with STEK based tickets al= l the time. That may well be a simpler design than trying to reuse ESNI. It also solves a= small hole in the ESNI-based proposal: the session key depends on the ESNI n= once, but the handshake key does not. -- Christian Huitema=20 > On Feb 28, 2019, at 2:34 PM, Martin Thomson wrote: >=20 > I probably don't have all the context, but when I start hearing about keep= ing public keys secret, I always think "why not a PSK?" Is there a reason t= hat wouldn't work here also? A PSK ensures that only those who have the key= can see that the query is for an entity with the PSK. You could use DH as w= ell to make the details of the query confidential from those as well. You d= on't get authentication unless you also have an asymmetric key, but that's e= asily doable (with TLS anyway). >=20 >> On Fri, Mar 1, 2019, at 05:05, Christian Huitema wrote: >>=20 >>> On 2/28/2019 6:28 AM, Michael Richardson wrote: >>> Christian Huitema wrote: >>>>> Okay, so, as I suspected, this is vulnerable to dictionary attacks if >>>>> the public key is leaked. Am I misunderstanding? If so, can you >>>>> explain why this is not the case? >>>=20 >>>> If the public key is leaked, anyone with the leaked key can impersonate= >>>> an authorized client, establish a connection, etc. The secrecy of the >>>> public key is what keeps this together. In all these schemes, there has= >>>> to be a secret that acts as the seed for the privates exchanges, and in= >>>> the scheme I propose that secret is the public discovery key of the ser= ver. >>>=20 >>> Since we have extensive public training that the "public key" is safe to= >>> disclose, this may be confusing for many, as this is no longer the case f= or this. >>>=20 >>> May I suggest different terminology? As the two halves of asymmetric key= ing >>> systems are mathematically equivalent, so maybe we could call it the >>> client-dual-key or something like that. >>=20 >> It is a server key, not a client key, but I see the issue. I was >> thinking of using "discovery key". Would that work? >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >> Attachments: >> * signature.asc >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd