From nobody Fri Mar 1 13:17:13 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 79464130F84; Fri, 1 Mar 2019 13:10:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnssd@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461348.6101.11304850245695149815.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:13 -0800 Archived-At: Subject: [dnssd] dnssd - Requested session has been scheduled 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, 01 Mar 2019 21:10:27 -0000 Dear David Schinazi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (2:00 requested) Monday, 25 March 2019, Afternoon Session II 1610-1810 Room Name: Berlin/Brussels size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/dnssd.ics Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: David Schinazi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: 6man dnsop doh dprive homenet quic mls core anima babel Second Priority: ipsecme intarea v6ops People who must be present: Barbara Stark Terry Manderson Eric Vyncke David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Mar 6 13:35: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 BF395130DD6 for ; Wed, 6 Mar 2019 13:35:56 -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 iEnRDOZiUPdt for ; Wed, 6 Mar 2019 13:35:54 -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 AB365126F72 for ; Wed, 6 Mar 2019 13:35:54 -0800 (PST) Received: from [10.244.195.212] (unknown [71.69.162.195]) (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 92DE029513 for ; Wed, 6 Mar 2019 16:35:53 -0500 (EST) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_132F1926-9FF3-480F-810D-EF6141C6B57F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <177759E0-61A8-4D15-9681-B39EE189AC70@bangj.com> References: <155190777424.14265.7018367118210440193.idtracker@ietfa.amsl.com> To: dnssd Date: Wed, 6 Mar 2019 16:35:52 -0500 X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-pusateri-dnssd-update-proxy-01.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, 06 Mar 2019 21:35:57 -0000 --Apple-Mail=_132F1926-9FF3-480F-810D-EF6141C6B57F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is an updated version of the Update proxy draft that fixes an error = locating the UPDATE primary server, adds a new section on how to = transition entirely to unicast service discovery, and cleans up some = text and formatting. I would love to have some discussion here before Prague! Thanks, Tom > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-pusateri-dnssd-update-proxy-01.txt > Date: March 6, 2019 at 4:29:34 PM EST > To: "Tom Pusateri" >=20 >=20 > A new version of I-D, draft-pusateri-dnssd-update-proxy-01.txt > has been successfully submitted by Tom Pusateri and posted to the > IETF repository. >=20 > Name: draft-pusateri-dnssd-update-proxy > Revision: 01 > Title: DNS Update Proxy for Service Discovery > Document date: 2019-03-06 > Group: Individual Submission > Pages: 18 > URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dnssd-update-proxy-01.= txt > Status: = https://datatracker.ietf.org/doc/draft-pusateri-dnssd-update-proxy/ > Htmlized: = https://tools.ietf.org/html/draft-pusateri-dnssd-update-proxy-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dnssd-update-proxy > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-pusateri-dnssd-update-proxy-01 >=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=_132F1926-9FF3-480F-810D-EF6141C6B57F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here = is an updated version of the Update proxy draft that fixes an error = locating the UPDATE primary server, adds a new section on how to = transition entirely to unicast service discovery, and cleans up some = text and formatting.

I= would love to have some discussion here before Prague!

Thanks,
Tom

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pusateri-dnssd-update-proxy-01.txt
Date: = March 6, 2019 at 4:29:34 PM = EST
To: = "Tom Pusateri" <pusateri@bangj.com>


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

Name: = draft-pusateri-dnssd-update-proxy
Revision: 01
Title:= = DNS Update Proxy for Service Discovery
Document = date: = 2019-03-06
Group: Individual Submission
Pages:= = 18
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dnssd-updat= e-proxy-01.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= 1
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnssd-upda= te-proxy
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-pusateri-dnssd-update= -proxy-01

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=_132F1926-9FF3-480F-810D-EF6141C6B57F-- From nobody Thu Mar 7 11:12: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 55542128709 for ; Thu, 7 Mar 2019 11:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 an1IfD0K_NOm for ; Thu, 7 Mar 2019 11:12:36 -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 55B0C128678 for ; Thu, 7 Mar 2019 11:12:36 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x27J4NYu045792 for ; Thu, 7 Mar 2019 14:12:35 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2r394rga32-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 07 Mar 2019 14:12:35 -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 x27JCXpT006407 for ; Thu, 7 Mar 2019 14:12:33 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x27JCRDI006236 for ; Thu, 7 Mar 2019 14:12:27 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 91A4D4005C2E for ; Thu, 7 Mar 2019 19:12:27 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id 817CE4005C2C for ; Thu, 7 Mar 2019 19:12:27 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0435.000; Thu, 7 Mar 2019 14:12:26 -0500 From: "STARK, BARBARA H" To: "dnssd@ietf.org" Thread-Topic: dnssd agenda Thread-Index: AdTVGaeZBP9WzkrXTragOzDO/d9X6Q== Date: Thu, 7 Mar 2019 19:12:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E0CE555@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.206.12] 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-03-07_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=313 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070128 Archived-At: Subject: [dnssd] dnssd 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: Thu, 07 Mar 2019 19:12:37 -0000 Does anyone have a request for dnssd agenda time? Barbara From nobody Thu Mar 7 11:26:52 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 A7B171277D9 for ; Thu, 7 Mar 2019 11:26:50 -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 ybG-Guka4sBY for ; Thu, 7 Mar 2019 11:26:48 -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 0EE901277D7 for ; Thu, 7 Mar 2019 11:26:48 -0800 (PST) Received: from [10.0.1.54] (172-125-168-43.lightspeed.rlghnc.sbcglobal.net [172.125.168.43]) (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 C08AF2968F; Thu, 7 Mar 2019 14:26:46 -0500 (EST) From: Tom Pusateri Message-Id: <501E6315-B59A-43B9-A2BC-AF589821BCB5@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7DBD0D14-6FDE-4D84-991F-713D9DB5FA1C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 14:26:45 -0500 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E0CE555@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: dnssd To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114E0CE555@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dnssd] dnssd 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: Thu, 07 Mar 2019 19:26:50 -0000 --Apple-Mail=_7DBD0D14-6FDE-4D84-991F-713D9DB5FA1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for asking! I would like 20 minutes to discuss Update proxy. https://tools.ietf.org/html/draft-pusateri-dnssd-update-proxy-01 = Tim and I would also like 5-10 minutes to discuss TIMEOUT resource = records since they are relevant to service registration protocol and = update proxy. = https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-02 = The Update proxy discussion should take precedence over the TIMEOUT = discussion if there=E2=80=99s not time for both. I=E2=80=99ll also note that I=E2=80=99ve contacted the volunteers to = work on the CHARTER several times and got absolutely zero responses back = and so rather than do it all by myself, I think we should re-discuss = interest at the meeting or on the list before the meeting. Thanks, Tom > On Mar 7, 2019, at 2:12 PM, STARK, BARBARA H wrote: >=20 > Does anyone have a request for dnssd agenda time? > Barbara >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_7DBD0D14-6FDE-4D84-991F-713D9DB5FA1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for asking!

I would like 20 minutes to discuss Update proxy.

= https://tools.ietf.org/html/draft-pusateri-dnssd-update-proxy-01

Tim and I = would also like 5-10 minutes to discuss TIMEOUT resource records since = they are relevant to service registration protocol and update = proxy.

= https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-02<= /a>





On Mar 7, 2019, at 2:12 PM, STARK, BARBARA H = <bs7652@att.com> = wrote:

Does anyone have a request for dnssd agenda time?
Barbara

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

= --Apple-Mail=_7DBD0D14-6FDE-4D84-991F-713D9DB5FA1C-- From nobody Thu Mar 7 13:51:23 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 ED4581311B0; Thu, 7 Mar 2019 13:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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 CbvhbbNrF8Is; Thu, 7 Mar 2019 13:51:17 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 90C1C1311A7; Thu, 7 Mar 2019 13:51:17 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x27LlX60022294; Thu, 7 Mar 2019 13:51:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=bOQswLEz9sjsyIO8iZuRF6KYXR3IuVGOdgx946vlVe0=; b=eTQ6Cp/cll0f3wD6VjBQrMcEMphfIjI1/ZWRI2y13fE0yvX4IB0e8hj5sRuQZMeaqxGx utZqCeSvwvlLPXFQNp/dCe4WiytvG9IKnZmdTPx//UygKKRZCRcw1XLa0R6Z2fCBCCQE tsmSAO06r0rZUNsagmoYAvnK6ozB/ni53+Ks1TgO01vkQmzSpwL+BnX+edXfyQvMYU8o pISLmZFZdrzEfXY8bcFJJCyGVSGZs4p3JJT8THB8lw18eqW270Et0dJp1UNln6ZjwFLv dqBjy5R9Ki5fETaIbQyPfsCVvzYKGsIegV2YhYAFDwaeQwP99MPoLAzBDCa+Hx/hDloL QA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2qysn9grt6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Mar 2019 13:51:15 -0800 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO000BDLNDBABF0@ma1-mtap-s02.corp.apple.com>; Thu, 07 Mar 2019 13:51:14 -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 <0PO000J00N3JSE00@nwk-mmpp-sz12.apple.com>; Thu, 07 Mar 2019 13:51:12 -0800 (PST) X-Va-A: X-Va-T-CD: 46089963636650ba3f6b170c8994862d X-Va-E-CD: 353f9aa2df9cb9d4362509d918922964 X-Va-R-CD: 3d4eee51cb88ed36173c756672172d4a X-Va-CD: 0 X-Va-ID: cf4751d7-e1ee-484a-93ed-ed0f02bf9948 X-V-A: X-V-T-CD: 46089963636650ba3f6b170c8994862d X-V-E-CD: 353f9aa2df9cb9d4362509d918922964 X-V-R-CD: 3d4eee51cb88ed36173c756672172d4a X-V-CD: 0 X-V-ID: 0ebcd53f-85df-4af7-b6a8-de426d048087 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-07_13:,, signatures=0 Received: from [17.230.129.183] (unknown [17.230.129.183]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO00041PNDBYQ90@nwk-mmpp-sz12.apple.com>; Thu, 07 Mar 2019 13:51:11 -0800 (PST) Sender: youenn@apple.com From: youenn fablet In-reply-to: Date: Thu, 07 Mar 2019 13:51:11 -0800 Cc: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org, dnssd Content-transfer-encoding: quoted-printable Message-id: References: To: Tom Pusateri X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_13:, , signatures=0 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: Thu, 07 Mar 2019 21:51:21 -0000 Hi Tom, Thanks for the feedback. Please find some comments inline, Y > On Feb 17, 2019, at 12:13 PM, Tom Pusateri wrote: >=20 > 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. It is at a RTCWeb/ICE/DNS-SD crossing point. Wherever that document goes, I think it is good to get feedback from all = groups. >=20 > 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. I think the scope of this proposal is narrower than your interpretation. A device may want to not expose its own private IP address to a web = page. In that case, it will register a MDNS name for its own private IP = address and disclose the MDNS name to the web page instead of its IP = address. While the idea is interesting and potentially useful, I think the = ability of a device to register names for other device IP addresses is = out of scope of this particular document. >=20 > 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. >=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 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. >=20 > List Item 3: >=20 > 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. This document might need clarification on that point: the IP address = that is registered is always from the device doing the MDNS = registration. Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94 on how to = best clarify this. > 3rd last paragraph: >=20 > "with both IPv4 and IPv6 addresses MUST expose a different mDNS name = for each address." >=20 > 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. >=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 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. Right, we could try to make a better suggestion here, as long as it = remains simple. Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93. >=20 > Thanks, > Tom >=20 >=20 From nobody Thu Mar 7 14:04:30 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 65F791311B0; Thu, 7 Mar 2019 14:04:28 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY_w-RVm7DvL; Thu, 7 Mar 2019 14:04:25 -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 411921275E9; Thu, 7 Mar 2019 14:04:25 -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 15567296D2; Thu, 7 Mar 2019 17:04:24 -0500 (EST) From: Tom Pusateri Message-Id: <761DD42B-5C35-480C-9C7C-860A3002BB65@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF9B2855-0B44-42C0-BCE7-54431F9F3290" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 17:04:23 -0500 In-Reply-To: Cc: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org, dnssd To: youenn fablet References: X-Mailer: Apple Mail (2.3445.102.3) 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: Thu, 07 Mar 2019 22:04:29 -0000 --Apple-Mail=_FF9B2855-0B44-42C0-BCE7-54431F9F3290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok, it was not obvious from all the components that the IP addresses = were owned. In that case, I agree that normal mDNS applies and no = extension to RFC 6762 is required. Maybe a better description of which host is announcing the name and = which host is resolving the name would help? Unless it=E2=80=99s all on = the same host and then, why use mDNS? Thanks, Tom > On Mar 7, 2019, at 4:51 PM, youenn fablet = wrote: >=20 > Hi Tom, >=20 >=20 > Thanks for the feedback. > Please find some comments inline, > Y >=20 >> On Feb 17, 2019, at 12:13 PM, Tom Pusateri > wrote: >>=20 >> 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. >=20 > It is at a RTCWeb/ICE/DNS-SD crossing point. > Wherever that document goes, I think it is good to get feedback from = all groups. >=20 >>=20 >> 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. >=20 > I think the scope of this proposal is narrower than your = interpretation. > A device may want to not expose its own private IP address to a web = page. > In that case, it will register a MDNS name for its own private IP = address and disclose the MDNS name to the web page instead of its IP = address. > While the idea is interesting and potentially useful, I think the = ability of a device to register names for other device IP addresses is = out of scope of this particular document. >=20 >>=20 >> 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. >>=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 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. >>=20 >> List Item 3: >>=20 >> 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. >=20 > This document might need clarification on that point: the IP address = that is registered is always from the device doing the MDNS = registration. > Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94 = on how to = best clarify this. >=20 >> 3rd last paragraph: >>=20 >> "with both IPv4 and IPv6 addresses MUST expose a different mDNS name = for each address." >>=20 >> 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. >>=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 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. >=20 > Right, we could try to make a better suggestion here, as long as it = remains simple. > Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93 = . >=20 >>=20 >> Thanks, >> Tom >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd = --Apple-Mail=_FF9B2855-0B44-42C0-BCE7-54431F9F3290 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok, = it was not obvious from all the components that the IP addresses were = owned. In that case, I agree that normal mDNS applies and no extension = to RFC 6762 is required.

Maybe a better description of which host is announcing the = name and which host is resolving the name would help? Unless it=E2=80=99s = all on the same host and then, why use mDNS?

Thanks,
Tom

On Mar 7, 2019, at 4:51 PM, youenn fablet <yfablet=3D40apple.com@dmarc.ietf.org> wrote:

Hi = Tom,


Thanks for = the feedback.
Please find = some comments inline,
= Y

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

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.

It is at a RTCWeb/ICE/DNS-SD crossing point.
Wherever that = document goes, I think it is good to get feedback from all = groups.


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.

I think the = scope of this proposal is narrower than your interpretation.
A device may = want to not expose its own private IP address to a web page.
In that case, = it will register a MDNS name for its own private IP address and disclose = the MDNS name to the web page instead of its IP address.
While the = idea is interesting and potentially useful, I think the ability of a = device to register names for other device IP addresses is out of scope = of this particular 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=99= re extending it.

This document might need clarification on that point: the IP = address that is registered is always from the device doing the MDNS = registration.
Discussion is = ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D""> on how to best clarify = this.

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=99t = 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.

Right, we could try to make a better suggestion here, as long = as it remains simple.
Discussion is ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D"">.


Thanks,
Tom



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

= --Apple-Mail=_FF9B2855-0B44-42C0-BCE7-54431F9F3290-- From nobody Thu Mar 7 14: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 BF4771311FA; Thu, 7 Mar 2019 14:36:00 -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 IwtBJWIMTIm4; Thu, 7 Mar 2019 14:35:58 -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 AEECC1311F6; Thu, 7 Mar 2019 14:35:58 -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 7EA8B296DA; Thu, 7 Mar 2019 17:35:57 -0500 (EST) From: Tom Pusateri Message-Id: <0F7AE115-8EFA-416E-9FEE-C3FEC29A698C@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA5B4027-3468-45ED-BB11-5134CA0A3730" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 17:35:56 -0500 In-Reply-To: <761DD42B-5C35-480C-9C7C-860A3002BB65@bangj.com> Cc: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org, dnssd To: youenn fablet References: <761DD42B-5C35-480C-9C7C-860A3002BB65@bangj.com> X-Mailer: Apple Mail (2.3445.102.3) 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: Thu, 07 Mar 2019 22:36:01 -0000 --Apple-Mail=_EA5B4027-3468-45ED-BB11-5134CA0A3730 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To be more clear, by =E2=80=9Cwhy use mDNS?=E2=80=9D if the announcing = host and the resolving host are the same, I really mean it would be = wasteful to use mDNS for inter process communication and wake up every = mobile device radio on the same link, but if you think this is still = your best option, you should spell it out. Thanks, Tom > On Mar 7, 2019, at 5:04 PM, Tom Pusateri wrote: >=20 > Ok, it was not obvious from all the components that the IP addresses = were owned. In that case, I agree that normal mDNS applies and no = extension to RFC 6762 is required. >=20 > Maybe a better description of which host is announcing the name and = which host is resolving the name would help? Unless it=E2=80=99s all on = the same host and then, why use mDNS? >=20 > Thanks, > Tom >=20 >> On Mar 7, 2019, at 4:51 PM, youenn fablet = > wrote: >>=20 >> Hi Tom, >>=20 >>=20 >> Thanks for the feedback. >> Please find some comments inline, >> Y >>=20 >>> On Feb 17, 2019, at 12:13 PM, Tom Pusateri > wrote: >>>=20 >>> 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. >>=20 >> It is at a RTCWeb/ICE/DNS-SD crossing point. >> Wherever that document goes, I think it is good to get feedback from = all groups. >>=20 >>>=20 >>> 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. >>=20 >> I think the scope of this proposal is narrower than your = interpretation. >> A device may want to not expose its own private IP address to a web = page. >> In that case, it will register a MDNS name for its own private IP = address and disclose the MDNS name to the web page instead of its IP = address. >> While the idea is interesting and potentially useful, I think the = ability of a device to register names for other device IP addresses is = out of scope of this particular document. >>=20 >>>=20 >>> 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. >>>=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 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. >>>=20 >>> List Item 3: >>>=20 >>> This makes it seem like normal mDNS is occurring here when it=E2=80=99= s 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. >>=20 >> This document might need clarification on that point: the IP address = that is registered is always from the device doing the MDNS = registration. >> Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94 = on how to = best clarify this. >>=20 >>> 3rd last paragraph: >>>=20 >>> "with both IPv4 and IPv6 addresses MUST expose a different mDNS name = for each address." >>>=20 >>> 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. >>>=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 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. >>=20 >> Right, we could try to make a better suggestion here, as long as it = remains simple. >> Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93 = . >>=20 >>>=20 >>> Thanks, >>> Tom >>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_EA5B4027-3468-45ED-BB11-5134CA0A3730 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = be more clear, by =E2=80=9Cwhy use mDNS?=E2=80=9D if the announcing host = and the resolving host are the same, I really mean it would be wasteful = to use mDNS for inter process communication and wake up every mobile = device radio on the same link, but if you think this is still your best = option, you should spell it out.

Thanks,
Tom

On Mar = 7, 2019, at 5:04 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

Ok, it was not obvious = from all the components that the IP addresses were owned. In that case, = I agree that normal mDNS applies and no extension to RFC 6762 is = required.

Maybe a = better description of which host is announcing the name and which host = is resolving the name would help? Unless it=E2=80=99s all on the same = host and then, why use mDNS?

Thanks,
Tom

On Mar 7, 2019, at 4:51 PM, youenn fablet = <yfablet=3D40apple.com@dmarc.ietf.org> wrote:

Hi = Tom,


Thanks for = the feedback.
Please find = some comments inline,
= Y

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

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.

It is at a RTCWeb/ICE/DNS-SD crossing point.
Wherever that = document goes, I think it is good to get feedback from all = groups.


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.

I think the = scope of this proposal is narrower than your interpretation.
A device may = want to not expose its own private IP address to a web page.
In that case, = it will register a MDNS name for its own private IP address and disclose = the MDNS name to the web page instead of its IP address.
While the = idea is interesting and potentially useful, I think the ability of a = device to register names for other device IP addresses is out of scope = of this particular 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=99= re extending it.

This document might need clarification on that point: the IP = address that is registered is always from the device doing the MDNS = registration.
Discussion is = ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D""> on how to best clarify = this.

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=99t = 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.

Right, we could try to make a better suggestion here, as long = as it remains simple.
Discussion is ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D"">.


Thanks,
Tom



_______________________________________________
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

= --Apple-Mail=_EA5B4027-3468-45ED-BB11-5134CA0A3730-- From nobody Thu Mar 7 14:45: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 94F1013120F; Thu, 7 Mar 2019 14:45:32 -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 OeCwpX7McLUm; Thu, 7 Mar 2019 14:45:30 -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 060A51311C4; Thu, 7 Mar 2019 14:45:29 -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 x27MfpqG050650; Thu, 7 Mar 2019 14:45:28 -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=0fclr87PGexqcaRVanmgXaJDa5ikxTMtBAkWvGJ4E6c=; b=CSaqc7RvV18X6d7N42SK5Et84PXP2ap1GC3TlYHo7BifS5o9iXFzi4yxFSwWGDUj+8K9 sAAO+FvzdzvE9M+SsppVIwXwg+5YyzZphG7sV0qLoy4q8aFQgbAEc1EnQg1tK64GfJ// d6Z788VeIbWF1jI0SJjGwbZmlLlvlbFjUD1HVPrEKfSFqokQZDlmR4qDVkgOHscOjD5r N0lJ+NjPFMWuLlHzxajTWCZhEJ/T0KUOnHuAWQwjRU27qw3HC1for15prbAr4qOwYK6+ 46v/MRnSNWxd2bXCs1Ehav3bL32fj8kKCNfqPLa/isi7IMF3x0Xzlh5/cozf2LPgZlOA uw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2qyqd46egv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Mar 2019 14:45:28 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1BgXPFzxl0lZrxmPhPdJuQ)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO000HVJPVKAFB0@ma1-mtap-s02.corp.apple.com>; Thu, 07 Mar 2019 14:45:28 -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 <0PO000G00O8ZD900@nwk-mmpp-sz12.apple.com>; Thu, 07 Mar 2019 14:45:27 -0800 (PST) X-Va-A: X-Va-T-CD: 46089963636650ba3f6b170c8994862d X-Va-E-CD: 171740ecac2ad434e37d98dc99469f23 X-Va-R-CD: c86a0762f803f6ca7b13bd98680e1e43 X-Va-CD: 0 X-Va-ID: a15d0df0-33ad-4ff7-bf34-99bc54fe0a79 X-V-A: X-V-T-CD: 46089963636650ba3f6b170c8994862d X-V-E-CD: 171740ecac2ad434e37d98dc99469f23 X-V-R-CD: c86a0762f803f6ca7b13bd98680e1e43 X-V-CD: 0 X-V-ID: 9e1d72a6-f920-4003-8b69-0b0fc356fcd8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-07_14:,, signatures=0 Received: from [17.230.129.183] (unknown [17.230.129.183]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO000J6BPVOXBE0@nwk-mmpp-sz12.apple.com>; Thu, 07 Mar 2019 14:45:25 -0800 (PST) Sender: youenn@apple.com From: youenn fablet Message-id: Date: Thu, 07 Mar 2019 14:45:24 -0800 In-reply-to: <0F7AE115-8EFA-416E-9FEE-C3FEC29A698C@bangj.com> Cc: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org, dnssd To: Tom Pusateri References: <761DD42B-5C35-480C-9C7C-860A3002BB65@bangj.com> <0F7AE115-8EFA-416E-9FEE-C3FEC29A698C@bangj.com> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_14:, , signatures=0 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: Thu, 07 Mar 2019 22:45:33 -0000 --Boundary_(ID_1BgXPFzxl0lZrxmPhPdJuQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Mar 7, 2019, at 2:35 PM, Tom Pusateri wrote: >=20 > To be more clear, by =E2=80=9Cwhy use mDNS?=E2=80=9D if the announcing = host and the resolving host are the same, I really mean it would be = wasteful to use mDNS for inter process communication and wake up every = mobile device radio on the same link, but if you think this is still = your best option, you should spell it out. The common case is for the two to be different. Nothing prevents the two to be the same though and it should equally = work. >=20 > Thanks, > Tom >=20 >> On Mar 7, 2019, at 5:04 PM, Tom Pusateri > wrote: >>=20 >> Ok, it was not obvious from all the components that the IP addresses = were owned. In that case, I agree that normal mDNS applies and no = extension to RFC 6762 is required. >>=20 >> Maybe a better description of which host is announcing the name and = which host is resolving the name would help? Unless it=E2=80=99s all on = the same host and then, why use mDNS? >>=20 >> Thanks, >> Tom >>=20 >>> On Mar 7, 2019, at 4:51 PM, youenn fablet = > wrote: >>>=20 >>> Hi Tom, >>>=20 >>>=20 >>> Thanks for the feedback. >>> Please find some comments inline, >>> Y >>>=20 >>>> On Feb 17, 2019, at 12:13 PM, Tom Pusateri > wrote: >>>>=20 >>>> 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. >>>=20 >>> It is at a RTCWeb/ICE/DNS-SD crossing point. >>> Wherever that document goes, I think it is good to get feedback from = all groups. >>>=20 >>>>=20 >>>> 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. >>>=20 >>> I think the scope of this proposal is narrower than your = interpretation. >>> A device may want to not expose its own private IP address to a web = page. >>> In that case, it will register a MDNS name for its own private IP = address and disclose the MDNS name to the web page instead of its IP = address. >>> While the idea is interesting and potentially useful, I think the = ability of a device to register names for other device IP addresses is = out of scope of this particular document. >>>=20 >>>>=20 >>>> 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. >>>>=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 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. >>>>=20 >>>> List Item 3: >>>>=20 >>>> This makes it seem like normal mDNS is occurring here when it=E2=80=99= s 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. >>>=20 >>> This document might need clarification on that point: the IP address = that is registered is always from the device doing the MDNS = registration. >>> Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94 = on how to = best clarify this. >>>=20 >>>> 3rd last paragraph: >>>>=20 >>>> "with both IPv4 and IPv6 addresses MUST expose a different mDNS = name for each address." >>>>=20 >>>> 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. >>>>=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 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. >>>=20 >>> Right, we could try to make a better suggestion here, as long as it = remains simple. >>> Discussion is ongoing at = https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93 = . >>>=20 >>>>=20 >>>> Thanks, >>>> Tom >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 --Boundary_(ID_1BgXPFzxl0lZrxmPhPdJuQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Mar 7, 2019, at 2:35 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

To be more clear, by = =E2=80=9Cwhy use mDNS?=E2=80=9D if the announcing host and the resolving = host are the same, I really mean it would be wasteful to use mDNS for = inter process communication and wake up every mobile device radio on the = same link, but if you think this is still your best option, you should = spell it out.

The = common case is for the two to be different.
Nothing prevents = the two to be the same though and it should equally work.


Thanks,
Tom

On Mar 7, 2019, at 5:04 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

Ok, it was not obvious = from all the components that the IP addresses were owned. In that case, = I agree that normal mDNS applies and no extension to RFC 6762 is = required.

Maybe a = better description of which host is announcing the name and which host = is resolving the name would help? Unless it=E2=80=99s all on the same = host and then, why use mDNS?

Thanks,
Tom

On Mar 7, 2019, at 4:51 PM, youenn fablet = <yfablet=3D40apple.com@dmarc.ietf.org> wrote:

Hi = Tom,


Thanks for = the feedback.
Please find = some comments inline,
= Y

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

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.

It is at a RTCWeb/ICE/DNS-SD crossing point.
Wherever that = document goes, I think it is good to get feedback from all = groups.


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.

I think the = scope of this proposal is narrower than your interpretation.
A device may = want to not expose its own private IP address to a web page.
In that case, = it will register a MDNS name for its own private IP address and disclose = the MDNS name to the web page instead of its IP address.
While the = idea is interesting and potentially useful, I think the ability of a = device to register names for other device IP addresses is out of scope = of this particular 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=99= re extending it.

This document might need clarification on that point: the IP = address that is registered is always from the device doing the MDNS = registration.
Discussion is = ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/94<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D""> on how to best clarify = this.

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=99t = 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.

Right, we could try to make a better suggestion here, as long = as it remains simple.
Discussion is ongoing at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/93<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 13px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" class=3D"">.


Thanks,
Tom



_______________________________________________
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


= --Boundary_(ID_1BgXPFzxl0lZrxmPhPdJuQ)-- From nobody Fri Mar 8 07:57: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 338631313E0 for ; Fri, 8 Mar 2019 07:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=uni.lu 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 t5pHlNax4omA for ; Fri, 8 Mar 2019 07:57:04 -0800 (PST) Received: from smtp1.uni.lu (smtp1.uni.lu [IPv6:2001:a18:a:c5::d]) (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 758B8131307 for ; Fri, 8 Mar 2019 07:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1552060623; x=1583596623; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=zTpRndO5UEztrArEAOV6Jl4O/dd3iZX0M/C0KbxKjvA=; b=jMTGwOXFA9YZJuaOeKUYfNa2RZsgAI0RAIzTtm0uiB34c34/p8ZPElyi Sslrov7nCT3wTsDCSoiOVGtMrEu0CkVzc5EX5YnTXwx5ux8HCFFafQk5E MiXZnkX+y9G1wWfywM38kjiHlN/Cnsx6A8vGUANmOH41F+p0jJ5mndXao DQJBD9wHNPGnuZlBIAwxgYiCbmJJw7tW1pox6/15pVjMAMM55vJ8J/wep y8x0RBtUwbCroGxD2yJrC4UH5LkLYBFFj44XyFUZ8a5Exnyg6+WXGriiy niI95JeNhGPS6yVjpxxi5CAH4Bo8rH7dMLVSBsa+prFRWAOI921sepAUQ Q==; Authentication-Results: smtp1.uni.lu; spf=Fail smtp.mailfrom=daniel.kaiser@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu X-IronPort-AV: E=Sophos; i="5.58,456,1544482800"; d="scan'208,217"; a="19807577" References: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> From: Daniel KAISER To: Christian Huitema , , CC: , Message-ID: Date: Fri, 8 Mar 2019 16:56:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AEAE110476481A886F8EECA2" Content-Language: en-US X-Originating-IP: [10.240.10.16] X-ClientProxiedBy: Widow2017.uni.lux (2001:a18:a:90::71) To lydia2017.uni.lux (2001:a18:a:90::83) 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: Fri, 08 Mar 2019 15:57:19 -0000 --------------AEAE110476481A886F8EECA2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Regarding public keys and directory attacks: If we would use *pairwise* symmetric keys instead of "secret" public keys, such directory attacks could not be run efficiently, and we could use hinting to avoid trial decryption. The draft on bloomfilter hints I posted would be a first step towards making pairwise-key-based discovery more efficient in terms of discovery messages needed. Further, as discussed before, using pairwise keys, clients that use a service cannot infer which other clients use the same service; and a leaked key only affects a single pair of client and server. Pairing: For establishing the pairwise keys, we could use (and build on) the mechanism described in draft-ietf-dnssd-pairing-05. If we stick to "secret" public keys, how do we distribute the public keys to authorized clients? (I also agree that we should not refer to these keys as public keys.) Kind regards, Daniel Kaiser On 2/28/19 7:03 PM, Christian Huitema wrote: > > > 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 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 > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Dr. Daniel Kaiser Research Associate SnT- Interdisciplinary Centre for Security, Reliability and Trust University of Luxembourg Maison du Nombre (MNO) 6, avenue de la Fonte L-4364 Esch-sur-Alzette Office: E02 0225-010 --------------AEAE110476481A886F8EECA2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Regarding public keys and directory attacks:
If we would use *pairwise* symmetric keys instead of "secret" public keys, such directory attacks could not be run efficiently, and we could use hinting to avoid trial decryption.
The draft on bloomfilter hints I posted would be a first step towards making pairwise-key-based discovery more efficient in terms of discovery messages needed.
Further, as discussed before, using pairwise keys, clients that
use a service cannot infer which other clients use the same service;
and a leaked key only affects a single pair of client and server.

Pairing:
For establishing the pairwise keys, we could use (and build on) the mechanism described in    
draft-ietf-dnssd-pairing-05.
If we stick to "secret" public keys, how do we distribute the public keys to authorized clients?
(I also agree that we should not refer to these keys as public keys.)

Kind regards,
Daniel Kaiser




On 2/28/19 7:03 PM, Christian Huitema wrote:


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


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


-- 

Dr. Daniel Kaiser
Research Associate
SnT- Interdisciplinary Centre for Security, Reliability and Trust

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010
--------------AEAE110476481A886F8EECA2-- From nobody Sun Mar 10 16:52:41 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 9343B126C87; Sun, 10 Mar 2019 16:52:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155226195955.31037.8774257495212469346@ietfa.amsl.com> Date: Sun, 10 Mar 2019 16:52:39 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-17.txt 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: Sun, 10 Mar 2019 23:52:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-17.txt Pages : 38 Date : 2019-03-10 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-17 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-17 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 10 21:01:30 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 1E248130EDF for ; Sun, 10 Mar 2019 21:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngzusCYSsRDC for ; Sun, 10 Mar 2019 21:01:25 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 2E66A130EDE for ; Sun, 10 Mar 2019 21:01:25 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx147.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1h3C7s-000kwH-Tm for dnssd@ietf.org; Mon, 11 Mar 2019 05:01:23 +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 1h3C7m-00051f-4A for dnssd@ietf.org; Mon, 11 Mar 2019 00:01:18 -0400 Received: (qmail 18703 invoked from network); 11 Mar 2019 04:01:09 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Mar 2019 04:01:09 -0000 References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> To: dnssd 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= X-Forwarded-Message-Id: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> Message-ID: <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> Date: Sun, 10 Mar 2019 21:01:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------85EC322CDEB10FDF31FD92F6" 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.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vOwD6uBp52V0ZSi89KPzQx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxZg4GbETB7AHy+rqM5l99NFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kB7L9qFZEB58fINh4BP9MqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezYBFjKYeYprI6D9W+xTY9pPwUimsNGvJJilSn4u6QSZFBcRD/r+pNH /uUq4/zF3yIs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53tGWQiV0zRVsA5SL7kYV1JnAMgFPp7+h3kLe NmBV53UGedkc1ukIkPpoCznP/QmQQ2kCT443T22I/4oVBzRiheNRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/IAhemhJdBSJkER04dYNqSf7G3ch6MdB0XuALpEgtIRSdxZ/cxSnpMWdGZZ8 NIOHnN40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 04:01:28 -0000 This is a multi-part message in MIME format. --------------85EC322CDEB10FDF31FD92F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is my prototype design of private discovery using TLS/ESNI. I will try having an actual prototype in place before Prague. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt Date: Sun, 10 Mar 2019 20:58:25 -0700 From: internet-drafts@ietf.org To: Daniel Kaiser , Christian Huitema A new version of I-D, draft-huitema-dnssd-tls-privacy-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-dnssd-tls-privacy Revision: 00 Title: Private Discovery with TLS-ESNI Document date: 2019-03-10 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/ Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy Abstract: DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by developing a private discovery profile for UDP based transports using TLS, such as DTLS and QUIC. The profile is based on using the Encrypted SNI extension. We also define a standalone private discovery service, that can be combined with arbitrary applications in the same way as DNS-SD. 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 --------------85EC322CDEB10FDF31FD92F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

This is my prototype design of private discovery using TLS/ESNI. I will try having an actual prototype in place before Prague.

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
Date: Sun, 10 Mar 2019 20:58:25 -0700
From: internet-drafts@ietf.org
To: Daniel Kaiser <daniel.kaiser@uni-konstanz.de>, Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-huitema-dnssd-tls-privacy-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dnssd-tls-privacy
Revision: 00
Title: Private Discovery with TLS-ESNI
Document date: 2019-03-10
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/
Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy


Abstract:
DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting
services. This information includes host names, network parameters,
and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises.

We propose to solve this problem by developing a private discovery
profile for UDP based transports using TLS, such as DTLS and QUIC.
The profile is based on using the Encrypted SNI extension. We also
define a standalone private discovery service, that can be combined
with arbitrary applications in the same way as DNS-SD.



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

--------------85EC322CDEB10FDF31FD92F6-- From nobody Sun Mar 10 21:56: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 72CEE130F04 for ; Sun, 10 Mar 2019 21:56:01 -0700 (PDT) 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 DLDQwFdrSiQx for ; Sun, 10 Mar 2019 21:55:58 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 8D357130EF1 for ; Sun, 10 Mar 2019 21:55:58 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2B4pg3P058738; Sun, 10 Mar 2019 21:55:52 -0700 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=1bhMaMCULCkUzSYW99K+5xv8TqLF5L+0aoY2ze9sDrk=; b=KvLGYgnOvauYd3kpM4D7kycjJBKY9/qki4hW4ZwiHPxKuWw2/GlQxb5zMrIm2oIbl34p ZAEiT0QfXNX7R9sGPzeM55jBQZC/tfpZ/Jd0UmsjCEKkeSUUr8BRvudYO125muvuskjs Qw14/qwjewcnAZcqFDyIzIHkBsI3ZsD61Sfdfw2GyjflQs1UdFR3ce/Ul/p1abcw+/GX QPryiSKzmrzy895Om3WARrq2Yvb5bW8cQrXUTWQIwKlfTm0aGzH0IhbBLI8lHu89vy30 8YMHspnVKyLHvWK2WYPRW4mAgKSBpy1YtzKTXCKv6y5NRuQQUcyNeLiW8l3UZ1y7kFHm sw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2r4dc3dk7d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 10 Mar 2019 21:55:51 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_308n5QGSILivJlds5c8KhQ)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO600CTTR13X210@ma1-mtap-s02.corp.apple.com>; Sun, 10 Mar 2019 21:55:51 -0700 (PDT) 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 <0PO600300Q1FQT00@nwk-mmpp-sz09.apple.com>; Sun, 10 Mar 2019 21:55:51 -0700 (PDT) X-Va-A: X-Va-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-Va-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01 X-Va-R-CD: 1766e3bf804fb0608209bc33f08e9ab8 X-Va-CD: 0 X-Va-ID: 0b6e0efa-6d48-401c-bc45-efdcc40281b7 X-V-A: X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-V-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01 X-V-R-CD: 1766e3bf804fb0608209bc33f08e9ab8 X-V-CD: 0 X-V-ID: 8029a0e6-dd5e-4384-82f5-e0d5d0aa172d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_05:,, signatures=0 Received: from [17.234.9.252] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO6003PZR10G370@nwk-mmpp-sz09.apple.com>; Sun, 10 Mar 2019 21:55:49 -0700 (PDT) Sender: bradley@apple.com From: Bob Bradley Message-id: Date: Sun, 10 Mar 2019 21:55:47 -0700 In-reply-to: <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> Cc: dnssd To: Christian Huitema References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_05:, , signatures=0 Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 04:56:02 -0000 --Boundary_(ID_308n5QGSILivJlds5c8KhQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT It looks like this is intended to find a specific server on the network using that server's discovery key to encrypt the request. If the client doesn't know which servers might be on the network, would it need to send a multicast packet for each server it has a key for? For example, if I'm paired with 20 devices then when discovery starts, would I send 20 multicast packets? Are there plans for a mechanism to announce the availability of a server? For example, if I start discovery (which sends an initial batch of multicast packets) and then a few seconds later a server becomes available, will server have a way to notify the client of its availability? > On Mar 10, 2019, at 9:01 PM, Christian Huitema wrote: > > This is my prototype design of private discovery using TLS/ESNI. I will try having an actual prototype in place before Prague. > > -- Christian Huitema > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt > Date: Sun, 10 Mar 2019 20:58:25 -0700 > From: internet-drafts@ietf.org > To: Daniel Kaiser , Christian Huitema > > > A new version of I-D, draft-huitema-dnssd-tls-privacy-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-dnssd-tls-privacy > Revision: 00 > Title: Private Discovery with TLS-ESNI > Document date: 2019-03-10 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/ > Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy > > > Abstract: > DNS-SD (DNS Service Discovery) normally discloses information about > both the devices offering services and the devices requesting > services. This information includes host names, network parameters, > and possibly a further description of the corresponding service > instance. Especially when mobile devices engage in DNS Service > Discovery over Multicast DNS at a public hotspot, a serious privacy > problem arises. > > We propose to solve this problem by developing a private discovery > profile for UDP based transports using TLS, such as DTLS and QUIC. > The profile is based on using the Encrypted SNI extension. We also > define a standalone private discovery service, that can be combined > with arbitrary applications in the same way as DNS-SD. > > > > 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 > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Boundary_(ID_308n5QGSILivJlds5c8KhQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable It = looks like this is intended to find a specific server on the network = using that server's discovery key to encrypt the request. If the client = doesn't know which servers might be on the network, would it need to = send a multicast packet for each server it has a key for? For example, = if I'm paired with 20 devices then when discovery starts, would I send = 20 multicast packets?

Are there plans for a mechanism to announce the availability = of a server? For example, if I start discovery (which sends an initial = batch of multicast packets) and then a few seconds later a server = becomes available, will server have a way to notify the client of its = availability?

On Mar 10, 2019, at 9:01 PM, = Christian Huitema <huitema@huitema.net> wrote:

=20 =20

This = is my prototype design of private discovery using TLS/ESNI. I will try having an actual prototype in place before = Prague.

-- Christian Huitema



-------- Forwarded Message -------- =
Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
Date: Sun, 10 Mar 2019 20:58:25 -0700
From: internet-drafts@ietf.org
To: Daniel Kaiser <daniel.kaiser@uni-konsta= nz.de>, Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-huitema-dnssd-tls-privacy-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dnssd-tls-privacy
Revision: 00
Title: Private Discovery with TLS-ESNI
Document date: 2019-03-10
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-pr= ivacy-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/
Htmlized: ht= tps://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy=


Abstract:
DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting
services. This information includes host names, network parameters,
and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises.

We propose to solve this problem by developing a private = discovery
profile for UDP based transports using TLS, such as DTLS and = QUIC.
The profile is based on using the Encrypted SNI extension. We = also
define a standalone private discovery service, that can be combined
with arbitrary applications in the same way as DNS-SD.



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

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

= --Boundary_(ID_308n5QGSILivJlds5c8KhQ)-- From nobody Sun Mar 10 22:53: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 B84D2130F0B for ; Sun, 10 Mar 2019 22:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow6nAFu4uoXn for ; Sun, 10 Mar 2019 22:53:44 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 66B401277E7 for ; Sun, 10 Mar 2019 22:53:44 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1h3Dsb-0001Rb-M9 for dnssd@ietf.org; Mon, 11 Mar 2019 06:53:42 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1h3DsY-0007b5-Hr for dnssd@ietf.org; Mon, 11 Mar 2019 01:53:39 -0400 Received: (qmail 2792 invoked from network); 11 Mar 2019 05:53:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Mar 2019 05:53:37 -0000 To: Bob Bradley Cc: dnssd References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@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: <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> Date: Sun, 10 Mar 2019 22:53:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.215 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.18) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tAESgystGAT2ZCHXerh7ud602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxTKM3mKk1pZq0cs3eKkBLoFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl61SQyjC5ILv tLBA4CEVU/NqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+a9HWwMUNATk5aqJgNL5XJKDg5/bq7ChmPMN Ycw1QSmRGlyfj97UFWbC/ogX71Gx+BIaQXm4s3JvHymY2ieNAMtm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhihfVX7Nwkf86OVuF6l8Zp2++NTKQHNkjJg8xvPcdYB8Xv0lqRWmYZel4DctY KBjcJP27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 05:53:47 -0000 On 3/10/2019 9:55 PM, Bob Bradley wrote: > It looks like this is intended to find a specific server on the > network using that server's discovery key to encrypt the request. If > the client doesn't know which servers might be on the network, would > it need to send a multicast packet for each server it has a key for? > For example, if I'm paired with 20 devices then when discovery starts, > would I send 20 multicast packets? As designed, the answer is yes, the client would send 20 packets. I understand very well that there is an alternative design in which the server sends a packet announcing its arrival, and then every interested client discovers the server and contacts it. I believe that the scaling is actually equivalent: 1) In my design's worst case, the client sends N packets, and P servers who are present perform O(N) trial decryptions. Total O(P.N2). 2) In the server announce design, P arriving servers send P packets upon arrival on the network, and O(N) clients perform N trial decryptions. Total O(P.N2) as well. It is pretty hard to resolve that discussion without actual statistics, application scenario, etc. For example, it is not clear at all that "servers" will be listening all the time, versus listening only when the corresponding app is in focus, e.g. when several users start the same app and explain app instances to find each other. > > Are there plans for a mechanism to announce the availability of a > server? For example, if I start discovery (which sends an initial > batch of multicast packets) and then a few seconds later a server > becomes available, will server have a way to notify the client of its > availability? Again, this depends a lot on application scenario. In a peer-to-peer scenario, the roles of server and client are flexible. Peer A comes first, finds nobody there, starts listening in server mode. Peer B arrives a moment later, starts in client mode, engages in discovery, succeeds. -- Christian Huitema From nobody Mon Mar 11 00:03:19 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 BCCA41310BF for ; Mon, 11 Mar 2019 00:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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 TxGIk18hTbjn for ; Mon, 11 Mar 2019 00:03:14 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 6BDAA1310B5 for ; Mon, 11 Mar 2019 00:03:14 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2B6v6MT051059; Mon, 11 Mar 2019 00:03:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=HEK0OYFSjJZji1ONSYeB2jIYVpYFRa+IWMk9dC0VNpI=; b=V9J8IKOxJsd5VQOkim1vKF+1KAyBdoKRjwufbNZj7rkIryd0/wOcAB9jgEdtT5WuHzmS cHXyFibg7Go1D9XRRq2nLDbQ52yB5ff5Cq7he7x8BdXsY8puwV/SJ2qmcjaFKXGFX9GG i5u/N/bkbvtXcaBtnZmeQEg/KO5YnplNUudqPhhQjzmWFtDo2ts3rhIeEGGztrJEzAPr AnIrub/clAd0jJ9UfUIQBuU2Q1K/70Ahnqm4M1TMmm9myWCIibplXNq/x3CFXXBT2h4P khxufYRJYHCU8l/aXMSZ93hW19dYSxYz4+y+n8MGFUIRxQ4Jv0rKRBUO/yyUaF7BRhUS zA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2r4da786js-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Mar 2019 00:03:07 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO60029EWX5I480@ma1-mtap-s02.corp.apple.com>; Mon, 11 Mar 2019 00:03:06 -0700 (PDT) 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 <0PO600M00WS2KH00@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 00:03:05 -0700 (PDT) X-Va-A: X-Va-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-Va-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01 X-Va-R-CD: 1766e3bf804fb0608209bc33f08e9ab8 X-Va-CD: 0 X-Va-ID: e43c8f8c-aec7-46e3-8537-5602c9fa28cf X-V-A: X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-V-E-CD: 1d0bcb06104f6ef6c8d207c9abde8e01 X-V-R-CD: 1766e3bf804fb0608209bc33f08e9ab8 X-V-CD: 0 X-V-ID: 5466c5ee-2888-4d5a-81be-d9726924ae7c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_06:,, signatures=0 Received: from [17.234.9.252] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO600AZBWX4HF00@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 00:03:05 -0700 (PDT) Sender: bradley@apple.com From: Bob Bradley In-reply-to: <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> Date: Mon, 11 Mar 2019 00:03:03 -0700 Cc: dnssd Message-id: References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_06:, , signatures=0 Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 07:03:17 -0000 > On Mar 10, 2019, at 10:53 PM, Christian Huitema wrote: > > On 3/10/2019 9:55 PM, Bob Bradley wrote: >> It looks like this is intended to find a specific server on the >> network using that server's discovery key to encrypt the request. If >> the client doesn't know which servers might be on the network, would >> it need to send a multicast packet for each server it has a key for? >> For example, if I'm paired with 20 devices then when discovery starts, >> would I send 20 multicast packets? > > As designed, the answer is yes, the client would send 20 packets. I > understand very well that there is an alternative design in which the > server sends a packet announcing its arrival, and then every interested > client discovers the server and contacts it. I believe that the scaling > is actually equivalent: > > 1) In my design's worst case, the client sends N packets, and P servers > who are present perform O(N) trial decryptions. Total O(P.N2). > > 2) In the server announce design, P arriving servers send P packets upon > arrival on the network, and O(N) clients perform N trial decryptions. > Total O(P.N2) as well. In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device. As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then: Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses. Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses. > It is pretty hard to resolve that discussion without actual statistics, > application scenario, etc. For example, it is not clear at all that > "servers" will be listening all the time, versus listening only when the > corresponding app is in focus, e.g. when several users start the same > app and explain app instances to find each other. > >> >> Are there plans for a mechanism to announce the availability of a >> server? For example, if I start discovery (which sends an initial >> batch of multicast packets) and then a few seconds later a server >> becomes available, will server have a way to notify the client of its >> availability? > > Again, this depends a lot on application scenario. In a peer-to-peer > scenario, the roles of server and client are flexible. Peer A comes > first, finds nobody there, starts listening in server mode. Peer B > arrives a moment later, starts in client mode, engages in discovery, > succeeds. > > -- Christian Huitema > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Mar 11 00:14:32 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 BE298131115 for ; Mon, 11 Mar 2019 00:14:30 -0700 (PDT) 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, 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 L6D3qO-eMGn0 for ; Mon, 11 Mar 2019 00:14:29 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 CF48313104F for ; Mon, 11 Mar 2019 00:14:28 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1h3F8b-0007fD-OE for dnssd@ietf.org; Mon, 11 Mar 2019 08:14:23 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1h3F8T-000403-3X for dnssd@ietf.org; Mon, 11 Mar 2019 03:14:10 -0400 Received: (qmail 25161 invoked from network); 11 Mar 2019 07:14:07 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Mar 2019 07:14:06 -0000 To: Bob Bradley Cc: dnssd References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <2f106571-676b-8852-5c3e-38601306f2f1@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: <179f5539-d336-6497-c027-c03686bef08c@huitema.net> Date: Mon, 11 Mar 2019 00:14:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C6070D02B6C410B164959525" 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.19) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oYmgFk0lva2xGNaaAkb4MN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxxSu5A18p74AZnBvdZAHiClDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j56H4LNdLx5R4LmAS6U2pDgU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMRUrRLEbmN2hOWkm+jjl7mqPwUimsNGvJJilSn4u6QSZA729fga3ljs oXrqCrRpoows95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53qJ/6IMS6dQ3kd+UR7sHsZfAMgFPp7+h3kLe NmBV53UGTisBPLbohtX2hZnkB0oJXf6/HT74iwXzqpsaxpIMGzhRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/H/F9n7vBiJVyH1aslqSF4coR+PypV5Z5Sfz/IlJBgJ68rMgFGxC0xSok+fi i+Mknt40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 07:14:31 -0000 This is a multi-part message in MIME format. --------------C6070D02B6C410B164959525 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/11/2019 12:03 AM, Bob Bradley wrote: >> As designed, the answer is yes, the client would send 20 packets. I >> understand very well that there is an alternative design in which the >> server sends a packet announcing its arrival, and then every intereste= d >> client discovers the server and contacts it. I believe that the scalin= g >> is actually equivalent: >> >> 1) In my design's worst case, the client sends N packets, and P server= s >> who are present perform O(N) trial decryptions. Total O(P.N2). >> >> 2) In the server announce design, P arriving servers send P packets up= on >> arrival on the network, and O(N) clients perform N trial decryptions. >> Total O(P.N2) as well. > In (1), there are N multicast packets per client and P unicast response= s from paired servers. In (2), there is 1 multicast request per client an= d P unicast from paired servers. Many devices act as both client and serv= er. Multicast vs unicast can make a big difference in the number of packe= ts processed by each device. > > As an example, my device has 40 paired devices and the network has abou= t 300 devices browsing for and offering services (by looking at mDNS). If= we assume other devices have a similar number of paired devices then: > > Approach 1: 12000 multicast requests (and trial decryptions) and 40 uni= cast responses. > Approach 2: 300 multicast requests (and trial decryptions) and 40 unica= st responses. Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work. But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small. -- Christian Huitema --------------C6070D02B6C410B164959525 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/11/2019 12:03 AM, Bob Bradley wrote:
As designed, the answer is yes, the client would send 20 packets. I
understand very well that there is an alternative design in which the
server sends a packet announcing its arrival, and then every interested
client discovers the server and contacts it. I believe that the scaling
is actually equivalent:

1) In my design's worst case, the client sends N packets, and P servers
who are present perform O(N) trial decryptions. Total O(P.N2).

2) In the server announce design, P arriving servers send P packets upon
arrival on the network, and O(N) clients perform N trial decryptions.
Total O(P.N2) as well.

In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.

As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:

Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work.

But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small.

-- Christian Huitema

--------------C6070D02B6C410B164959525-- From nobody Mon Mar 11 08:34: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 8C12B128B01 for ; Mon, 11 Mar 2019 08:33:59 -0700 (PDT) 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 0Oi8xYcV0sjl for ; Mon, 11 Mar 2019 08:33:58 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 15B8A124B0C for ; Mon, 11 Mar 2019 08:33:58 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2BFVWtH043814; Mon, 11 Mar 2019 08:33:50 -0700 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=kGNDrJwylrZXqeZ9Gx+TojBcr2nZUqnbsGYgfkhjEG4=; b=oEKFAWXVklTALGUgO/W3/usnnHNMJHgUxfhkWusKcQGeBZz9bZLjysw5UmA1iVSBRPWj YGmIpvGi7EmFGrSY5O8W6X0+FeZDeoHbLcnK0Hlcju6JHUSDbDgFjYAvFiu2OJs29eGE bMcIJ2i4C6+dbm334a11bkUtXZed0Z9qvHMnFBIsr7epA49zsKoVZD317fdQ7Dq6L/8X COhSuBHmUiltmc5k0ohaPA2ccRVygoH6DWFmO7O5JfGUef+i/X3mUonEXltPsHYgDiUn MzAdluTU5ELMHACLUSFAQkA8am8V/Os2en5VKrBfn/NnIozr54Tq3lZbqismmONN2r77 eQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2r4da7fhsx-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Mar 2019 08:33:49 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_N+6ydIKIqlgSKt3SOCaqKw)" 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 <0PO70004RKKAS2F0@ma1-mtap-s03.corp.apple.com>; Mon, 11 Mar 2019 08:33:47 -0700 (PDT) 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 <0PO700A00K7BN700@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 08:33:46 -0700 (PDT) X-Va-A: X-Va-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-Va-E-CD: 73fd81e39f7123add50a9943e2d3e256 X-Va-R-CD: 38097f5f91ac0986f9cb12414439efcc X-Va-CD: 0 X-Va-ID: f4b3927a-eee9-49d2-a794-9e05db807845 X-V-A: X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-V-E-CD: 73fd81e39f7123add50a9943e2d3e256 X-V-R-CD: 38097f5f91ac0986f9cb12414439efcc X-V-CD: 0 X-V-ID: fd2f1ef7-99a2-411a-bf61-d12f08f70807 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_12:,, signatures=0 Received: from [17.234.127.135] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO7006E6KK91L10@nwk-mmpp-sz12.apple.com>; Mon, 11 Mar 2019 08:33:46 -0700 (PDT) Sender: bradley@apple.com From: Bob Bradley Message-id: Date: Mon, 11 Mar 2019 08:33:43 -0700 In-reply-to: <179f5539-d336-6497-c027-c03686bef08c@huitema.net> Cc: dnssd To: Christian Huitema References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> <179f5539-d336-6497-c027-c03686bef08c@huitema.net> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_12:, , signatures=0 Archived-At: Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 15:34:00 -0000 --Boundary_(ID_N+6ydIKIqlgSKt3SOCaqKw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Mar 11, 2019, at 12:14 AM, Christian Huitema wrote: > On 3/11/2019 12:03 AM, Bob Bradley wrote: >>> As designed, the answer is yes, the client would send 20 packets. I >>> understand very well that there is an alternative design in which the >>> server sends a packet announcing its arrival, and then every interested >>> client discovers the server and contacts it. I believe that the scaling >>> is actually equivalent: >>> >>> 1) In my design's worst case, the client sends N packets, and P servers >>> who are present perform O(N) trial decryptions. Total O(P.N2). >>> >>> 2) In the server announce design, P arriving servers send P packets upon >>> arrival on the network, and O(N) clients perform N trial decryptions. >>> Total O(P.N2) as well. >> In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device. >> >> As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then: >> >> Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses. >> Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses. > Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work. > I think it would be 480000 trial decryptions for approach 1 (12000 packets * 40 keys) and 12000 trial decryptions for approach 2 (300 packets * 40 keys). > But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small. > Yes, my case may be higher than most. I can imagine the number of pairings growing as private, end-to-end communication becomes more prevalent. The main difference I see between approaches for the server discovery phase is which key is used. Approach 1 encrypts to the server's key. Approach 2 signs with its own key. This difference requires approach 1 to multiply the number of multicast request packets it sends by the number of server keys it has. Something to consider with approach 1 is using the client's discovery key in the first multicast request packet.This would avoid needing to send multiple multicast packets to discover servers. --Boundary_(ID_N+6ydIKIqlgSKt3SOCaqKw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
On Mar 11, 2019, at 12:14 AM, Christian Huitema <huitema@huitema.net> wrote:
On 3/11/2019 12:03 AM, Bob Bradley wrote:
As designed, the answer is yes, the client would send 20 packets. I
understand very well that there is an alternative design in which the
server sends a packet announcing its arrival, and then every interested
client discovers the server and contacts it. I believe that the scaling
is actually equivalent:

1) In my design's worst case, the client sends N packets, and P servers
who are present perform O(N) trial decryptions. Total O(P.N2).

2) In the server announce design, P arriving servers send P packets upon
arrival on the network, and O(N) clients perform N trial decryptions.
Total O(P.N2) as well.

In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.

As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:

Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work.

I think it would be 480000 trial decryptions for approach 1 (12000 packets * 40 keys) and 12000 trial decryptions for approach 2 (300 packets * 40 keys).

But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small.

Yes, my case may be higher than most. I can imagine the number of pairings growing as private, end-to-end communication becomes more prevalent.

The main difference I see between approaches for the server discovery phase is which key is used. Approach 1 encrypts to the server's key. Approach 2 signs with its own key. This difference requires approach 1 to multiply the number of multicast request packets it sends by the number of server keys it has.

Something to consider with approach 1 is using the client's discovery key in the first multicast request packet.This would avoid needing to send multiple multicast packets to discover servers.

--Boundary_(ID_N+6ydIKIqlgSKt3SOCaqKw)-- From nobody Mon Mar 11 11:06: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 5B1521277D8 for ; Mon, 11 Mar 2019 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voLtm_xXzB9e for ; Mon, 11 Mar 2019 11:06:16 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 01C21124BF6 for ; Mon, 11 Mar 2019 11:06:16 -0700 (PDT) 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 1h3PJQ-000BE8-B9 for dnssd@ietf.org; Mon, 11 Mar 2019 19:06:13 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1h3PJE-0003rk-HT for dnssd@ietf.org; Mon, 11 Mar 2019 14:05:57 -0400 Received: (qmail 23744 invoked from network); 11 Mar 2019 18:05:42 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Mar 2019 18:05:42 -0000 To: Bob Bradley Cc: dnssd References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> <179f5539-d336-6497-c027-c03686bef08c@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: <244e7041-4e04-f513-11ae-53ea65fafc3f@huitema.net> Date: Mon, 11 Mar 2019 11:05:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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.32) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nwyZMrF0z2P0TII8jCfDkd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxYo4FYp2ewVgBUerfHNSxllDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl118+4clI49c e/taUHgRz0tqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+ZbV1QYTPnZGbiCKnPeJqXuDg5/bq7ChmPMN Ycw1QSmRfZlIEJPHyZ+eybTLO9HCvp2GGX0sH6lEDpvBkSUS6Qtm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiukzbVwTlpzEqQskUS84syO+NTKQHNkjJg8xvPcdYB8Xlm45eDKY0zTzJ2HG 4elPGf27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-tls-privacy-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: Mon, 11 Mar 2019 18:06:17 -0000 On 3/11/2019 8:33 AM, Bob Bradley wrote: > > The main difference I see between approaches for the server discovery > phase is which key is used. Approach 1 encrypts to the server's key. > Approach 2 signs with its own key. This difference requires approach 1 > to multiply the number of multicast request packets it sends by the > number of server keys it has. > > Something to consider with approach 1 is using the client's discovery > key in the first multicast request packet.This would avoid needing to > send multiple multicast packets to discover servers. I think the use of server keys is more natural. There are many deployments in which the server does not identify the individual clients. I also think that for peer-to-peer applications it does not matter, because each peer can act as either server or client depending on circumstances. When I look at this thread, I think that the "excessive multicast" issues that you mention could be solved with a server broadcast message, "server X is now present on this network". It would be secured with the server discovery key, so only authorized clients would understand it. But i am concerned that this is a high cost and high risk message. High cost, because all clients need to run the trial description against all server keys that they know about, which has an O(N^2) feeling. Even if we discard the cost, the high risk is the replay attack. Suppose that an attacker has identified a server, and is capable of recording the broadcast announces from that server. The attacker can then replay the message, triggering paired clients to attempt communicating with the server. The attacker does not need to break any key, it just takes note of the addresses of the device responding to the server. I think we need a protection against the two variants of that attack: replay at a different time; and, replay at a different location. Of these, protection against replay in time is the easier -- just add a time stamp in the server's announce, an program the clients to discard old messages. Protection against replay at a different location would require adding a location information in the server's announce, and have clients discard the message if the location is not what they expect. Maybe the server could just copy their IPv6 address, and the client would be able to verify that the prefix is local. The same replay attack is also possible with the "client hello" proposal discussed in the draft, but the messages are much less powerful -- they are meant to trigger just one answer from one targeted server, not N answers from all the clients that happen to be present. -- Christian Huitema From nobody Mon Mar 11 13:17:28 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 B023C13118B for ; Mon, 11 Mar 2019 13:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoGeTlsRrtH3 for ; Mon, 11 Mar 2019 13:17:18 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 B5699131189 for ; Mon, 11 Mar 2019 13:17:17 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1h3RMI-0012ed-LH for dnssd@ietf.org; Mon, 11 Mar 2019 21:17:17 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1h3RMB-00006P-Gt for dnssd@ietf.org; Mon, 11 Mar 2019 16:17:13 -0400 Received: (qmail 8033 invoked from network); 11 Mar 2019 20:17:05 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Mar 2019 20:17:05 -0000 References: <155233177032.23114.1088138278464877459.idtracker@ietfa.amsl.com> To: dnssd 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= X-Forwarded-Message-Id: <155233177032.23114.1088138278464877459.idtracker@ietfa.amsl.com> Message-ID: <3b45407a-990b-0cbe-0c35-6058ac02a340@huitema.net> Date: Mon, 11 Mar 2019 13:17:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <155233177032.23114.1088138278464877459.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D72F99488E8AEC946AECB8C6" 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: ham X-Spampanel-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uu5t8KPQSs+G43LF1dW3LF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax9r852fGc6KMKHYAyxHylUVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5/z+vAHDOlLgrSj+stMQp+KXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsiW9oFktVPzI6hjS2b07n6no1vbZclGU0LBv+VfmTu+nHVm6JCF6xBl BzXX0dBPZvTFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeAbcIyxkjV8riHnAtAuDwf/ozswVgmo2tH4W 8yU3FuMqxPpxRpPLvhj7qeHRzzcdrqVqryftc5VE3Nmkk6gpkDc8CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDlzz30ut5rep1YQ6kSmdfK52f3MLbn7l3g+Lh7r9C5nLMbLz+Z/8OylBaLzk0 9eGtkky2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-01.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: Mon, 11 Mar 2019 20:17:27 -0000 This is a multi-part message in MIME format. --------------D72F99488E8AEC946AECB8C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I could squeeze in a quick update before the deadline. The new version fixes an error in Daniel's address, adds details on the replay attack, and also adds a discussion on "server arrival announce" that reflects the recent exchange with Bob. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-01.txt Date: Mon, 11 Mar 2019 12:16:10 -0700 From: internet-drafts@ietf.org To: Daniel Kaiser , Christian Huitema A new version of I-D, draft-huitema-dnssd-tls-privacy-01.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-dnssd-tls-privacy Revision: 01 Title: Private Discovery with TLS-ESNI Document date: 2019-03-11 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-01.txt Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/ Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-tls-privacy-01 Abstract: DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by developing a private discovery profile for UDP based transports using TLS, such as DTLS and QUIC. The profile is based on using the Encrypted SNI extension. We also define a standalone private discovery service, that can be combined with arbitrary applications in the same way as DNS-SD. 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 --------------D72F99488E8AEC946AECB8C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I could squeeze in a quick update before the deadline.

The new version fixes an error in Daniel's address, adds details on the replay attack, and also adds a discussion on "server arrival announce" that reflects the recent exchange with Bob.

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-dnssd-tls-privacy-01.txt
Date: Mon, 11 Mar 2019 12:16:10 -0700
From: internet-drafts@ietf.org
To: Daniel Kaiser <daniel.kaiser@uni.lu>, Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-huitema-dnssd-tls-privacy-01.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dnssd-tls-privacy
Revision: 01
Title: Private Discovery with TLS-ESNI
Document date: 2019-03-11
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-01.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/
Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy
Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-tls-privacy-01

Abstract:
DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting
services. This information includes host names, network parameters,
and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises.

We propose to solve this problem by developing a private discovery
profile for UDP based transports using TLS, such as DTLS and QUIC.
The profile is based on using the Encrypted SNI extension. We also
define a standalone private discovery service, that can be combined
with arbitrary applications in the same way as DNS-SD.



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

--------------D72F99488E8AEC946AECB8C6-- From nobody Mon Mar 11 14:59:12 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 7CD3C1311D3; Mon, 11 Mar 2019 14:59:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155234154246.23050.13050613828512015781@ietfa.amsl.com> Date: Mon, 11 Mar 2019 14:59:02 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-relay-02.txt 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: Mon, 11 Mar 2019 21:59:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Multicast DNS Discovery Relay Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-mdns-relay-02.txt Pages : 29 Date : 2019-03-11 Abstract: This document complements the specification of the Discovery Proxy for Multicast DNS-Based Service Discovery. It describes a lightweight relay mechanism, a Discovery Relay, which, when present on a link, allows remote clients, not attached to that link, to perform mDNS discovery operations on that link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-relay/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-mdns-relay-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-mdns-relay-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-relay-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:08:14 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 37B281310C6; Mon, 11 Mar 2019 15:08:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155234208813.23098.15948579715766746544@ietfa.amsl.com> Date: Mon, 11 Mar 2019 15:08:08 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-01.txt 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: Mon, 11 Mar 2019 22:08:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Stuart Cheshire Ted Lemon Filename : draft-ietf-dnssd-srp-01.txt Pages : 22 Date : 2019-03-11 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-srp-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 16:21:33 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 00B281279B1; Mon, 11 Mar 2019 16:21:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155234648597.23114.11118112693915893825@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:21:25 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-18.txt 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: Mon, 11 Mar 2019 23:21:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-18.txt Pages : 38 Date : 2019-03-11 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-18 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-18 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 16:52:48 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 A30BF13128C; Mon, 11 Mar 2019 16:52:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155234835562.23090.12162880364982721481@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:52:35 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-hybrid-09.txt 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: Mon, 11 Mar 2019 23:52:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Discovery Proxy for Multicast DNS-Based Service Discovery Author : Stuart Cheshire Filename : draft-ietf-dnssd-hybrid-09.txt Pages : 37 Date : 2019-03-11 Abstract: This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-09 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-hybrid-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-hybrid-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 17:26:30 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 80A43131242 for ; Mon, 11 Mar 2019 17:26:20 -0700 (PDT) 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 hwFzEQiCJzhN for ; Mon, 11 Mar 2019 17:26:17 -0700 (PDT) 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 9121B13121B for ; Mon, 11 Mar 2019 17:26:17 -0700 (PDT) Received: from [192.168.12.8] (174-099-147-122.biz.spectrum.com [174.99.147.122]) (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 6A10C29D3F for ; Mon, 11 Mar 2019 20:26:16 -0400 (EDT) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_3D22ECF2-0505-41CB-B2AB-929D4D8603BA" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <84A76287-DBD8-4FC2-ADAC-A3CF822716A4@bangj.com> References: <155233479715.23070.14580718185398098231.idtracker@ietfa.amsl.com> To: dnssd Date: Mon, 11 Mar 2019 20:26:14 -0400 X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-pusateri-dnsop-private-subdomains-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: Tue, 12 Mar 2019 00:26:28 -0000 --Apple-Mail=_3D22ECF2-0505-41CB-B2AB-929D4D8603BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 During the re-charter discussion last summer in Montr=C3=A9al, I = presented some observations about service discovery to help focus our = future work. 1. We should transition from using mDNS to using unicast DNS when = possible for privacy, performance, and resource conservation. When we do = use multicast, it should be for initial discovery but not for data = transfer. 2. Some services are personal. Some services are meant to be openly = shared, some are private. 3. Some services are location dependent but not necessarily network = attachment dependent. Think on campus but attached cellular. The Update proxy that I submitted on 12 Feb is meant to stimulate a = discussion for #1. This drafty draft below is meant for discussion on #2. It describes a = method of creating personal subdomains for sharing private services. = Unlike some of the other privacy solutions being discussed, it is not = intended for use over mDNS but only over unicast DNS. Since it is still = a work in progress, it would benefit from some other collaborators and = so if you read the draft and have some contributions to make, I would = love to work together. Protecting service discovery is not a security = solution on its own. It=E2=80=99s just one more piece of the puzzle to = not leak private information. Thanks and see you in Prague. Tom > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-pusateri-dnsop-private-subdomains-00.txt > Date: March 11, 2019 at 4:06:37 PM EDT > To: "Tom Pusateri" >=20 >=20 > A new version of I-D, draft-pusateri-dnsop-private-subdomains-00.txt > has been successfully submitted by Tom Pusateri and posted to the > IETF repository. >=20 > Name: draft-pusateri-dnsop-private-subdomains > Revision: 00 > Title: Private DNS Subdomains > Document date: 2019-03-11 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-private-subdomai= ns-00.txt > Status: = https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-subdomains/ > Htmlized: = https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdomains-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-private-subdoma= ins >=20 >=20 > Abstract: > This document describes a method of providing private DNS subdomains > such that each subdomain can be shared among multiple devices of a > single owner or group. A private subdomain can be used for sharing > personal services while increasing privacy and limiting knowledge of > scarce resources. >=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=_3D22ECF2-0505-41CB-B2AB-929D4D8603BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 During the re-charter discussion last summer in Montr=C3=A9al, = I presented some observations about service discovery to help focus our = future work.

1. We = should transition from using mDNS to using unicast DNS when possible for = privacy, performance, and resource conservation. When we do use = multicast, it should be for initial discovery but not for data = transfer.
2. Some services are personal. Some = services are meant to be openly shared, some are private.
3. Some services are location dependent but not necessarily = network attachment dependent. Think on campus but attached = cellular.

The Update proxy that I submitted on 12 Feb is meant to = stimulate a discussion for #1.

This = drafty draft below is meant for discussion on #2. It describes a method = of creating personal subdomains for sharing private services. Unlike = some of the other privacy solutions being discussed, it is not intended = for use over mDNS but only over unicast DNS. Since it is still a work in = progress, it would benefit from some other collaborators and so if you = read the draft and have some contributions to make, I would love to work = together. Protecting service discovery is not a security solution on its = own. It=E2=80=99s just one more piece of the puzzle to not leak private = information.

Thanks and see you in = Prague.

Tom

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pusateri-dnsop-private-subdomains-00.txt
Date: = March 11, 2019 at 4:06:37 PM = EDT
To: = "Tom Pusateri" <pusateri@bangj.com>


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

Name: = draft-pusateri-dnsop-private-subdomains
Revision: 00
Title: Private = DNS Subdomains
Document date: 2019-03-11
Group:= = Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-priva= te-subdomains-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-s= ubdomains/
Htmlized: =       https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdom= ains-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-priv= ate-subdomains


Abstract:
  This document describes = a method of providing private DNS subdomains
=   such that each subdomain can be shared among multiple = devices of a
  single owner or group.  A = private subdomain can be used for sharing
=   personal services while increasing privacy and limiting = knowledge of
  scarce resources.




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=_3D22ECF2-0505-41CB-B2AB-929D4D8603BA-- From nobody Mon Mar 11 21:21:26 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 DFF1C131272 for ; Mon, 11 Mar 2019 21:21:24 -0700 (PDT) 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 ZMroHmhdLhqE for ; Mon, 11 Mar 2019 21:21:22 -0700 (PDT) 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 36114130EB1 for ; Mon, 11 Mar 2019 21:21:22 -0700 (PDT) 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 53E5729D82 for ; Tue, 12 Mar 2019 00:21:21 -0400 (EDT) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_F14A9D90-FF3F-4247-A981-E76EC138D979" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 12 Mar 2019 00:21:18 -0400 References: <155233479715.23070.14580718185398098231.idtracker@ietfa.amsl.com> <84A76287-DBD8-4FC2-ADAC-A3CF822716A4@bangj.com> To: dnssd In-Reply-To: <84A76287-DBD8-4FC2-ADAC-A3CF822716A4@bangj.com> Message-Id: <15A71FF9-26DB-4404-93F9-64BEA6F4417F@bangj.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-pusateri-dnsop-private-subdomains-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: Tue, 12 Mar 2019 04:21:25 -0000 --Apple-Mail=_F14A9D90-FF3F-4247-A981-E76EC138D979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It just occurred to me that I made the solution for query/responses = overly complex in order to use caching at existing resolvers. The more = obvious and simple solution is to directly query the authoritative = servers using signed queries over TLS. This should remove the entire = encoding/decoding encrypted resource record text. I don=E2=80=99t think = this causes a problem because the number of devices is likely small and = the query rate low. I=E2=80=99ll push out another version shortly on github but it won=E2=80=99= t get published in the internet-draft archive until the freeze is = lifted. So keep that in mind if you read this before the -01 version is = available. Thanks, Tom > On Mar 11, 2019, at 8:26 PM, Tom Pusateri wrote: >=20 > During the re-charter discussion last summer in Montr=C3=A9al, I = presented some observations about service discovery to help focus our = future work. >=20 > 1. We should transition from using mDNS to using unicast DNS when = possible for privacy, performance, and resource conservation. When we do = use multicast, it should be for initial discovery but not for data = transfer. > 2. Some services are personal. Some services are meant to be openly = shared, some are private. > 3. Some services are location dependent but not necessarily network = attachment dependent. Think on campus but attached cellular. >=20 > The Update proxy that I submitted on 12 Feb is meant to stimulate a = discussion for #1. >=20 > This drafty draft below is meant for discussion on #2. It describes a = method of creating personal subdomains for sharing private services. = Unlike some of the other privacy solutions being discussed, it is not = intended for use over mDNS but only over unicast DNS. Since it is still = a work in progress, it would benefit from some other collaborators and = so if you read the draft and have some contributions to make, I would = love to work together. Protecting service discovery is not a security = solution on its own. It=E2=80=99s just one more piece of the puzzle to = not leak private information. >=20 > Thanks and see you in Prague. >=20 > Tom >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-pusateri-dnsop-private-subdomains-00.txt >> Date: March 11, 2019 at 4:06:37 PM EDT >> To: "Tom Pusateri" > >>=20 >>=20 >> A new version of I-D, draft-pusateri-dnsop-private-subdomains-00.txt >> has been successfully submitted by Tom Pusateri and posted to the >> IETF repository. >>=20 >> Name: draft-pusateri-dnsop-private-subdomains >> Revision: 00 >> Title: Private DNS Subdomains >> Document date: 2019-03-11 >> Group: Individual Submission >> Pages: 10 >> URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-private-subdomai= ns-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-subdomains/ = >> Htmlized: = https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdomains-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-private-subdoma= ins = >>=20 >>=20 >> Abstract: >> This document describes a method of providing private DNS = subdomains >> such that each subdomain can be shared among multiple devices of a >> single owner or group. A private subdomain can be used for sharing >> personal services while increasing privacy and limiting knowledge = of >> scarce resources. >>=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 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_F14A9D90-FF3F-4247-A981-E76EC138D979 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = just occurred to me that I made the solution for query/responses overly = complex in order to use caching at existing resolvers. The more obvious = and simple solution is to directly query the authoritative servers using = signed queries over TLS. This should remove the entire encoding/decoding = encrypted resource record text. I don=E2=80=99t think this causes a = problem because the number of devices is likely small and the query rate = low.

I=E2=80=99ll = push out another version shortly on github but it won=E2=80=99t get = published in the internet-draft archive until the freeze is lifted. So = keep that in mind if you read this before the -01 version is = available.

Thanks,
Tom


On Mar 11, 2019, at 8:26 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

During the re-charter = discussion last summer in Montr=C3=A9al, I presented some observations = about service discovery to help focus our future work.

1. We should transition from using mDNS = to using unicast DNS when possible for privacy, performance, and = resource conservation. When we do use multicast, it should be for = initial discovery but not for data transfer.
2. = Some services are personal. Some services are meant to be openly shared, = some are private.
3. Some services are location = dependent but not necessarily network attachment dependent. Think on = campus but attached cellular.

The Update proxy that I = submitted on 12 Feb is meant to stimulate a discussion for #1.

This drafty draft below = is meant for discussion on #2. It describes a method of creating = personal subdomains for sharing private services. Unlike some of the = other privacy solutions being discussed, it is not intended for use over = mDNS but only over unicast DNS. Since it is still a work in progress, it = would benefit from some other collaborators and so if you read the draft = and have some contributions to make, I would love to work together. = Protecting service discovery is not a security solution on its own. = It=E2=80=99s just one more piece of the puzzle to not leak private = information.

Thanks and see you in Prague.

Tom

Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for = draft-pusateri-dnsop-private-subdomains-00.txt
Date: March 11, 2019 at 4:06:37 PM EDT
To: "Tom Pusateri" <pusateri@bangj.com>


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

Name: = draft-pusateri-dnsop-private-subdomains
Revision: 00
Title: Private = DNS Subdomains
Document date: 2019-03-11
Group:= = Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-priva= te-subdomains-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-s= ubdomains/
Htmlized: =       https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdom= ains-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-priv= ate-subdomains


Abstract:
  This document describes = a method of providing private DNS subdomains
=   such that each subdomain can be shared among multiple = devices of a
  single owner or group.  A = private subdomain can be used for sharing
=   personal services while increasing privacy and limiting = knowledge of
  scarce resources.




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


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

= --Apple-Mail=_F14A9D90-FF3F-4247-A981-E76EC138D979-- From nobody Mon Mar 11 22:01: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 70E4713127E for ; Mon, 11 Mar 2019 22:01:34 -0700 (PDT) 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 sbDZZT7f2vl3 for ; Mon, 11 Mar 2019 22:01:32 -0700 (PDT) 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 6A6D6130EE0 for ; Mon, 11 Mar 2019 22:01:32 -0700 (PDT) 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 68D2C29D8C for ; Tue, 12 Mar 2019 01:01:31 -0400 (EDT) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_9043FBCA-5C79-49DC-A802-71C2ACFE8568" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 12 Mar 2019 01:01:28 -0400 References: <155233479715.23070.14580718185398098231.idtracker@ietfa.amsl.com> <84A76287-DBD8-4FC2-ADAC-A3CF822716A4@bangj.com> <15A71FF9-26DB-4404-93F9-64BEA6F4417F@bangj.com> To: dnssd In-Reply-To: <15A71FF9-26DB-4404-93F9-64BEA6F4417F@bangj.com> Message-Id: <3C56750A-0F30-4B22-9C55-C956104CBC64@bangj.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-pusateri-dnsop-private-subdomains-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: Tue, 12 Mar 2019 05:01:34 -0000 --Apple-Mail=_9043FBCA-5C79-49DC-A802-71C2ACFE8568 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the noise. The updated version can be found here: = https://github.com/pusateri/draft-pusateri-dnsop-private-subdomains/blob/m= aster/draft-pusateri-dnsop-private-subdomains.txt = I=E2=80=99ll keep tuning it and submit it on 3/23 when draft submission = opens up again. Thanks, Tom > On Mar 12, 2019, at 12:21 AM, Tom Pusateri wrote: >=20 > It just occurred to me that I made the solution for query/responses = overly complex in order to use caching at existing resolvers. The more = obvious and simple solution is to directly query the authoritative = servers using signed queries over TLS. This should remove the entire = encoding/decoding encrypted resource record text. I don=E2=80=99t think = this causes a problem because the number of devices is likely small and = the query rate low. >=20 > I=E2=80=99ll push out another version shortly on github but it won=E2=80= =99t get published in the internet-draft archive until the freeze is = lifted. So keep that in mind if you read this before the -01 version is = available. >=20 > Thanks, > Tom >=20 >=20 >> On Mar 11, 2019, at 8:26 PM, Tom Pusateri > wrote: >>=20 >> During the re-charter discussion last summer in Montr=C3=A9al, I = presented some observations about service discovery to help focus our = future work. >>=20 >> 1. We should transition from using mDNS to using unicast DNS when = possible for privacy, performance, and resource conservation. When we do = use multicast, it should be for initial discovery but not for data = transfer. >> 2. Some services are personal. Some services are meant to be openly = shared, some are private. >> 3. Some services are location dependent but not necessarily network = attachment dependent. Think on campus but attached cellular. >>=20 >> The Update proxy that I submitted on 12 Feb is meant to stimulate a = discussion for #1. >>=20 >> This drafty draft below is meant for discussion on #2. It describes a = method of creating personal subdomains for sharing private services. = Unlike some of the other privacy solutions being discussed, it is not = intended for use over mDNS but only over unicast DNS. Since it is still = a work in progress, it would benefit from some other collaborators and = so if you read the draft and have some contributions to make, I would = love to work together. Protecting service discovery is not a security = solution on its own. It=E2=80=99s just one more piece of the puzzle to = not leak private information. >>=20 >> Thanks and see you in Prague. >>=20 >> Tom >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-pusateri-dnsop-private-subdomains-00.txt >>> Date: March 11, 2019 at 4:06:37 PM EDT >>> To: "Tom Pusateri" > >>>=20 >>>=20 >>> A new version of I-D, draft-pusateri-dnsop-private-subdomains-00.txt >>> has been successfully submitted by Tom Pusateri and posted to the >>> IETF repository. >>>=20 >>> Name: draft-pusateri-dnsop-private-subdomains >>> Revision: 00 >>> Title: Private DNS Subdomains >>> Document date: 2019-03-11 >>> Group: Individual Submission >>> Pages: 10 >>> URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-private-subdomai= ns-00.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-subdomains/ = >>> Htmlized: = https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdomains-00 = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-private-subdoma= ins = >>>=20 >>>=20 >>> Abstract: >>> This document describes a method of providing private DNS = subdomains >>> such that each subdomain can be shared among multiple devices of a >>> single owner or group. A private subdomain can be used for = sharing >>> personal services while increasing privacy and limiting knowledge = of >>> scarce resources. >>>=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 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_9043FBCA-5C79-49DC-A802-71C2ACFE8568 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry= for the noise. The updated version can be found here:

https://github.com/pusateri/draft-pusateri-dnsop-private-subdom= ains/blob/master/draft-pusateri-dnsop-private-subdomains.txt

I=E2=80=99ll keep = tuning it and submit it on 3/23 when draft submission opens up = again.

Thanks,
Tom


On Mar 12, 2019, at 12:21 AM, Tom Pusateri <pusateri@bangj.com> = wrote:

It just occurred to me = that I made the solution for query/responses overly complex in order to = use caching at existing resolvers. The more obvious and simple solution = is to directly query the authoritative servers using signed queries over = TLS. This should remove the entire encoding/decoding encrypted resource = record text. I don=E2=80=99t think this causes a problem because the = number of devices is likely small and the query rate low.

I=E2=80=99ll push out = another version shortly on github but it won=E2=80=99t get published in = the internet-draft archive until the freeze is lifted. So keep that in = mind if you read this before the -01 version is available.

Thanks,
Tom


On Mar = 11, 2019, at 8:26 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

During the re-charter = discussion last summer in Montr=C3=A9al, I presented some observations = about service discovery to help focus our future work.

1. We should transition from using mDNS = to using unicast DNS when possible for privacy, performance, and = resource conservation. When we do use multicast, it should be for = initial discovery but not for data transfer.
2. = Some services are personal. Some services are meant to be openly shared, = some are private.
3. Some services are location = dependent but not necessarily network attachment dependent. Think on = campus but attached cellular.

The Update proxy that I = submitted on 12 Feb is meant to stimulate a discussion for #1.

This drafty draft below = is meant for discussion on #2. It describes a method of creating = personal subdomains for sharing private services. Unlike some of the = other privacy solutions being discussed, it is not intended for use over = mDNS but only over unicast DNS. Since it is still a work in progress, it = would benefit from some other collaborators and so if you read the draft = and have some contributions to make, I would love to work together. = Protecting service discovery is not a security solution on its own. = It=E2=80=99s just one more piece of the puzzle to not leak private = information.

Thanks and see you in Prague.

Tom

Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for = draft-pusateri-dnsop-private-subdomains-00.txt
Date: March 11, 2019 at 4:06:37 PM EDT
To: "Tom Pusateri" <pusateri@bangj.com>


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

Name: = draft-pusateri-dnsop-private-subdomains
Revision: 00
Title: Private = DNS Subdomains
Document date: 2019-03-11
Group:= = Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-priva= te-subdomains-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-private-s= ubdomains/
Htmlized: =       https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdom= ains-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-priv= ate-subdomains


Abstract:
  This document describes = a method of providing private DNS subdomains
=   such that each subdomain can be shared among multiple = devices of a
  single owner or group.  A = private subdomain can be used for sharing
=   personal services while increasing privacy and limiting = knowledge of
  scarce resources.




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


_______________________________________________
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

= --Apple-Mail=_9043FBCA-5C79-49DC-A802-71C2ACFE8568-- From nobody Fri Mar 22 14:02:08 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 5933C13157D for ; Fri, 22 Mar 2019 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iP/5WyvB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eANl4wlS 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 mcVTrdGmM_-B for ; Fri, 22 Mar 2019 14:02:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88ED131581 for ; Fri, 22 Mar 2019 14:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1553288524; x=1554498124; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yu0R6DCrvUuFmWzMu3N9qkf2DKjoqjxGyyEsYq65weo=; b=iP/5WyvBXYMaPFcFHE5YJ32hHo4yfYbD1d2fem+M2avmlxL7n76jb25O TuIyZpR+bqMG8aUyNSffKKuPZxWcDyaGhqfxVJnFfeZiU+UzuR2eiGMte lmLD5X4V/rS3RznT47K2a8E6tzcshVfPhVwHyaA9F5qjGYWtTIq40ogpm 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AeVuVwxXHVdl+Kri39fwAuAOmTejV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4H8NHVUR+9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAADIS5Vc/5JdJa1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2h0BAsnCoQEg0cDhFKKVkqBaJcvgS6BJANUDQEBGAs?= =?us-ascii?q?JhEACF4RlIjQJDQEBAwEBCQEDAm0cAQuFSwIEAQEhEQwBASwMDwIBCBoCJgI?= =?us-ascii?q?CAiULFRACBBODIgGBXQMVAQ6eCwKKFHGBL4J4AQEFgTUCDkFBgj8YggwIgQs?= =?us-ascii?q?kAYsxF4FAP4ERJwwTgkw+gmEBAQIBARaBMYMgMYImjHCEOZNnCQKHYYtVGYI?= =?us-ascii?q?CW4Uhi36LGIYCjSICBAIEBQIOAQEFgU04KIEYDghwFRohKgGCQQmCAQkag0u?= =?us-ascii?q?FFIU/coEojDsBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="250311253" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 21:02:03 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2ML23rM017396 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Mar 2019 21:02:03 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 16:02:03 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 16:02:02 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Mar 2019 17:02:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yu0R6DCrvUuFmWzMu3N9qkf2DKjoqjxGyyEsYq65weo=; b=eANl4wlSpRTPkHdzENODog56H7deh8flp4noVWbjLNbtacYDBtm0oowkQBu9nAHqUSBkkbtlvAXnoMmxoOllh87GC8A/IltGszj6Sg/6ZcXQqA38qwtwlZJjOY2C4JDYfA3EfZj7JTIiaHwcutje5bkdTPNHj8nisPMVtp5XRdg= Received: from BN6PR11MB4035.namprd11.prod.outlook.com (10.255.129.225) by BN6PR11MB1939.namprd11.prod.outlook.com (10.175.97.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 22 Mar 2019 21:02:01 +0000 Received: from BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8d84:c318:ef41:7fc6]) by BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8d84:c318:ef41:7fc6%5]) with mapi id 15.20.1709.017; Fri, 22 Mar 2019 21:02:01 +0000 From: "Jan Komissar (jkomissa)" To: "dnssd@ietf.org" Thread-Topic: [dnssd] I-D Action: draft-ietf-dnssd-push-18.txt Thread-Index: AQHU2GFC0cEglyuRIEuM73AKHsa9OqYX8SqA Date: Fri, 22 Mar 2019 21:02:01 +0000 Message-ID: <4CDE2C30-BF94-4C23-8718-8ADF8650CC31@cisco.com> References: <155234648597.23114.11118112693915893825@ietfa.amsl.com> In-Reply-To: <155234648597.23114.11118112693915893825@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkomissa@cisco.com; x-originating-ip: [173.38.117.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c55df8e9-7ec0-4698-eb3d-08d6af09a159 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1939; x-ms-traffictypediagnostic: BN6PR11MB1939: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(376002)(136003)(39860400002)(366004)(396003)(189003)(199004)(2501003)(6506007)(5640700003)(7736002)(229853002)(68736007)(25786009)(1730700003)(256004)(8936002)(81166006)(71200400001)(81156014)(6246003)(3846002)(6116002)(53936002)(5660300002)(186003)(36756003)(102836004)(66574012)(26005)(82746002)(66066001)(83716004)(6306002)(71190400001)(8676002)(6486002)(6512007)(33656002)(105586002)(58126008)(316002)(106356001)(2906002)(2616005)(6916009)(11346002)(76176011)(99286004)(446003)(97736004)(6436002)(478600001)(476003)(86362001)(486006)(305945005)(2351001)(14454004)(966005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1939; H:BN6PR11MB4035.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IroE42vwRomH6BA74kXLafct/JEvygeXgBnHdGDcFLIjSHZ/k4p1bmoHgaZQUcS+K5GX7+Qkt80yjlwMiDJ0I5qZ/Ezk8K5Xnmf4LavabcR6bEljUgJDbod6VTDcM7Wou7/G4AGIFMIyO9Fz90zbFZUU2H0nAinEzQxqfALQSgWitXi0gdpkkz6edaH1pM68x8fDle6DGmb09TQj7fq3XzrJs+gIlFV/FrkBu4AWIsbNO2wJER+/PEHv/5e+Qaeieq7Yf2ZgGG5N8xgNlX+SA3JeTy4kPnXpTtX2agcWSdtLYRDUJIMO1lrNaEH08tSCBe8uFZJcbnbn7jdqzjHiy9BSC4J502glQ3jSntLA97hCaMvKP/tmyrBELifjzcEq8Iljd1+huDll0ldpd/vPxiSlC/EMixERdPKQdgqiqOQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c55df8e9-7ec0-4698-eb3d-08d6af09a159 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 21:02:01.4764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1939 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-18.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: Fri, 22 Mar 2019 21:02:07 -0000 SGksDQoNCkEgY291cGxlIG9mIGNvbW1lbnRzOg0KNi4zLjEgUFVTSCBNZXNzYWdlDQpQZyAyMiwg cGFyYSAzOiANCj09PT09PT09PT09PQ0KSW4gdGhlIGRyYWZ0Og0KICAg4oCmIGFuZCBuYW1lcw0K ICAgYXBwZWFyaW5nIHdpdGhpbiBvbmx5IHRoZSBSREFUQSBvZiB0aGUgZm9sbG93aW5nIEROUyB0 eXBlcyBzaG91bGQgYmUNCiAgIGNvbXByZXNzZWQ6DQoNCiAgICAgIE5TLCBDTkFNRSwgUFRSLCBE TkFNRSwgU09BLCBNWCwgQUZTREIsIFJULCBLWCwgUlAsIFBYLCBTUlYsIE5TRUMNCg0KU3VnZ2Vz dGVkOg0KICAg4oCmIGFuZCBuYW1lcw0KICAgYXBwZWFyaW5nIHdpdGhpbiBSREFUQSBzaG91bGQg b25seSBiZSBjb21wcmVzc2VkIGluL2ZvciB0aGUgZm9sbG93aW5nIFJSIHR5cGVzIDoNCg0KICAg ICAgTlMsIENOQU1FLCBQVFIsIEROQU1FLCBTT0EsIE1YLCBBRlNEQiwgUlQsIEtYLCBSUCwgUFgs IFNSViwgTlNFQw0KDQpQZyAyMiwgcGFyYSA0Og0KPT09PT09PT09PT0NCkNvbnNpZGVyaW5nIHRo YXQgY2xpZW50cyBNVVNUIHRyZWF0IFBVU0ggbWVzc2FnZXMgbGFyZ2VyIHRoYW4gMTYzODIgYnl0 ZXMgYXMgYSBmYXRhbCBlcnJvciwgSSBzdWdnZXN0IGNoYW5naW5nDQoNCnRoZSBjaGFuZ2Ugbm90 aWZpY2F0aW9ucyBTSE9VTEQNCiAgIGJlIGNvbW11bmljYXRlZCBpbiBzZXBhcmF0ZSBQVVNIIG1l c3NhZ2VzDQoNCnRvDQoNCnRoZSBjaGFuZ2Ugbm90aWZpY2F0aW9ucyBNVVNUDQogICBiZSBjb21t dW5pY2F0ZWQgaW4gc2VwYXJhdGUgUFVTSCBtZXNzYWdlcw0KDQpwZyAzMywgTGluZSAzLCBsYXN0 IHdvcmQ6DQo9PT09PT09PT09PT09PT09PT09DQoiU2V2ZXIiIHNob3VsZCBiZSAiU2VydmVyLiIN Cg0KUmVnYXJkcywNCg0KSmFuLg0KDQoNCu+7v09uIDMvMTEvMTksIDc6MjIgUE0sICJkbnNzZCBv biBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8ZG5zc2QtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAg IA0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBFeHRlbnNpb25zIGZvciBTY2FsYWJsZSBETlMgU2VydmljZSBEaXNjb3Zlcnkg V0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBETlMg UHVzaCBOb3RpZmljYXRpb25zDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBUb20gUHVz YXRlcmkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0dWFydCBDaGVzaGlyZQ0KICAg IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTgudHh0DQogICAgCVBh Z2VzICAgICAgICAgICA6IDM4DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTktMDMtMTENCiAg ICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGUgRG9tYWluIE5hbWUgU3lzdGVtIChETlMpIHdh cyBkZXNpZ25lZCB0byByZXR1cm4gbWF0Y2hpbmcgcmVjb3Jkcw0KICAgICAgIGVmZmljaWVudGx5 IGZvciBxdWVyaWVzIGZvciBkYXRhIHRoYXQgYXJlIHJlbGF0aXZlbHkgc3RhdGljLiAgV2hlbg0K ICAgICAgIHRob3NlIHJlY29yZHMgY2hhbmdlIGZyZXF1ZW50bHksIEROUyBpcyBzdGlsbCBlZmZp Y2llbnQgYXQgcmV0dXJuaW5nDQogICAgICAgdGhlIHVwZGF0ZWQgcmVzdWx0cyB3aGVuIHBvbGxl ZCwgYXMgbG9uZyBhcyB0aGUgcG9sbGluZyByYXRlIGlzIG5vdA0KICAgICAgIHRvbyBoaWdoLiAg QnV0IHRoZXJlIGV4aXN0cyBubyBtZWNoYW5pc20gZm9yIGEgY2xpZW50IHRvIGJlDQogICAgICAg YXN5bmNocm9ub3VzbHkgbm90aWZpZWQgd2hlbiB0aGVzZSBjaGFuZ2VzIG9jY3VyLiAgVGhpcyBk b2N1bWVudA0KICAgICAgIGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIGEgY2xpZW50IHRvIGJlIG5v dGlmaWVkIG9mIHN1Y2ggY2hhbmdlcyB0bw0KICAgICAgIEROUyByZWNvcmRzLCBjYWxsZWQgRE5T IFB1c2ggTm90aWZpY2F0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc3NkLXB1c2gvDQogICAgDQogICAgVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTgNCiAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcHVzaC0xOA0KICAgIA0K ICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kbnNzZC1wdXNo LTE4DQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBkbnNzZCBtYWlsaW5nIGxpc3QNCiAgICBkbnNzZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QNCiAgICANCg0K From nobody Fri Mar 22 15:27: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 54A03124408 for ; Fri, 22 Mar 2019 15:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iiQR2MRR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LJhlVwkf 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 8kJXLv4E2hOs for ; Fri, 22 Mar 2019 15:27:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6220713158D for ; Fri, 22 Mar 2019 15:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5966; q=dns/txt; s=iport; t=1553293627; x=1554503227; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XHOtS6Ja+iU9nMg35d9F5R7Ys0YiCHqxZabMuMhKUUU=; b=iiQR2MRRfKpE7bHAU90a7iHHr3T1xHsdd0/bwTWq1CoxlvGFYUqnvBbM YglPBZCOJuBYU0pazvrCK5ivoJx++zQX8j8f725WLRw0D1FFAP/fDjM4S l8Eet1hOj90OEdERlN6T81iYRsBxyjoqzpA0/GywBWdwU1m/W3m2+00PH k=; IronPort-PHdr: =?us-ascii?q?9a23=3Amf+mRxcBaJGynCHH8jY8NZRnlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/bS89GcVZT1ZN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AADBYJVc/4YNJK1jHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwGBPVADaHQECycKhASDRwOEUopXSoFoly+BLoEkA1QNAQEYCwmEQAI?= =?us-ascii?q?XhGUiNAkNAQEDAQEJAQMCbRwBC4VLAgQBASERDAEBLAwPAgEIGgImAgICJQs?= =?us-ascii?q?VEAIEE4MiAYFdAxUBDp4UAooUcYEvgngBAQWBNQIOQUGCQBiCDAiBCyQBizE?= =?us-ascii?q?XgUA/gREnDBOCTD6CYQEBAgEBFoFHgwoxgiaKKoJGhDmTZwkCh2GLVRmCAlu?= =?us-ascii?q?FIYt+ixiGAo0iAgQCBAUCDgEBBYFNOCiBLnAVGiEqAYJBCYIBg26FFIU/coE?= =?us-ascii?q?ojEABgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="541860244" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 22:27:05 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MMR513022541 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Mar 2019 22:27:06 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 17:27:05 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 17:27:04 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Mar 2019 17:27:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XHOtS6Ja+iU9nMg35d9F5R7Ys0YiCHqxZabMuMhKUUU=; b=LJhlVwkf6DyIkkyHE0e8TyXogZH2JoqR+ytEoMvAoK0YRuEaGmbsHpb4hd1PuydgO3v4aBZqHY1/t2R9eieq3+m/wIhEpaYG6EhsvwBAwbJy6oh8w8nd0LShDkb8D6OruVJNEth+RZJvSeoajNDMnyBocYmtzzAJDztIRhm6C1o= Received: from BN6PR11MB4035.namprd11.prod.outlook.com (10.255.129.225) by BN6PR11MB1505.namprd11.prod.outlook.com (10.172.22.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Fri, 22 Mar 2019 22:27:03 +0000 Received: from BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8d84:c318:ef41:7fc6]) by BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8d84:c318:ef41:7fc6%5]) with mapi id 15.20.1709.017; Fri, 22 Mar 2019 22:27:03 +0000 From: "Jan Komissar (jkomissa)" To: "dnssd@ietf.org" Thread-Topic: [dnssd] I-D Action: draft-ietf-dnssd-mdns-relay-02.txt Thread-Index: AQHU2FYhYXRaIta0zEm0sHdf24UajKYYCQMA Date: Fri, 22 Mar 2019 22:27:03 +0000 Message-ID: <477BD308-DFAB-4324-9065-FB71E017D7F5@cisco.com> References: <155234154246.23050.13050613828512015781@ietfa.amsl.com> In-Reply-To: <155234154246.23050.13050613828512015781@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkomissa@cisco.com; x-originating-ip: [173.38.117.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a732e5b-54ac-4b28-04d3-08d6af158278 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1505; x-ms-traffictypediagnostic: BN6PR11MB1505: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(376002)(396003)(136003)(189003)(199004)(2501003)(2616005)(5660300002)(446003)(305945005)(486006)(66574012)(97736004)(229853002)(6486002)(6116002)(82746002)(3846002)(11346002)(476003)(68736007)(14454004)(7736002)(478600001)(25786009)(86362001)(71190400001)(83716004)(5024004)(36756003)(26005)(8936002)(966005)(6306002)(66066001)(33656002)(1730700003)(76176011)(58126008)(6506007)(106356001)(71200400001)(102836004)(105586002)(6436002)(5640700003)(186003)(6246003)(6916009)(2351001)(81166006)(81156014)(316002)(8676002)(99286004)(6512007)(256004)(53936002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1505; H:BN6PR11MB4035.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YbfZe0cPqFljfIv2CPms1tkvmF5a5KYL44SQ4Dd7sOaOO3+945gooqi14Pn7VmUOg60Iw7QTK6A7MPSIhPIvXSxrGJsbqgvUZ2oC7KANwpW6qgJ7i0cSIYr1Irz3htgiaeXngWfdMqImRLAsn+rdPdCwq0+V7MZJxeGasVbnesmgKWe3gtOzetVALXDiK6qIkbY/QNK1S5VY8UUn9olRt6NZyBlINaletb7EJTwuYXgeISwNuYvNIN8FD4/+yUzfP7XiUxS9CjoK2R8EIbXliorDUaV7dFrT9UzReNhKz47uyjiGgZe6Zx5D17VnDvpsbpYYgpOsh/Wg8eAUUnz/pjPvUjtkkG+pZUV3oVvIexqKPW2/HZ7dEjN9hmZD4tcPEZNW/kZ4CSyQLRUWqUsKauTJ2tEPQMNPhx6vfne7K9I= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3a732e5b-54ac-4b28-04d3-08d6af158278 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 22:27:03.6240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1505 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-relay-02.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: Fri, 22 Mar 2019 22:27:11 -0000 SGksDQoNCkEgZmV3IGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQ6DQoNClNlY3Rpb24gMiBUZXJtaW5v bG9neSAocGcuIDQpDQo9PT09PT09PT09PT09PT09PT09PT09PT0NCk5pdDogSSB3b3VsZCBpbnNl cnQgdGhpcyBwaHJhc2UsIGp1c3QgYmUgdmVyeSBjbGVhcjoNCkRpc2NvdmVyeSBSZWxheQkJQSBu ZXR3b3JrIHNlcnZpY2UsIGFzIHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50LCB3aGljaC4uLg0K DQptdWx0aWNhc3QgbGluazoNCkl0IHNlZW1zIGtpbmQgb2Ygb2RkIHRoYXQgdGhpcyBwYXJhZ3Jh cGggY29udGFpbnMgcGFydCBvZiB0aGUgcmF0aW9uYWxlIGZvciB0aGUgY3JlYXRpb24gb2YgdGhp cyBuZXcgc2VydmljZSBkaXNjb3ZlcnkgaW5mcmFzdHJ1Y3R1cmUuIE1pZ2h0IGl0IG5vdCBiZSBi ZXR0ZXIgcGxhY2VkIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQ/DQoNClNlY3Rpb24gNDogUGcg OToNCj09PT09PT09PT09PT0NCkZpcnN0IHBhcmE6IExpbmUgMzog4oCmIEZRRE4gYXMgKmFuKiBB dXRoZW50aWNhdGlvbuKApg0KDQpTZWN0aW9uIDggRFNQIFRMVnMsIHBnIDE0DQo9PT09PT09PT09 PT09PT09PT09PT0NCk5pdDogVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBsYXJnZXN0IG51bWJl ciBvZiBEU08gVExWcyBvZiBhbnkgZG9jdW1lbnQgc28gZmFyLiBJIHN1Z2dlc3QgZHJvcHBpbmcg dGhlIHdvcmQgIm1vZGVzdC4iDQoNClNlY3Rpb24gOC4yIG1ETlMgTGluayBEYXRhIERpc2NvbnRp bnVlLCBwZyAxNA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpQYXJh IDEsIExpbmUgNCwgbml0OiBSZW1vdmUgdGhlIGZpcnN0IGluc3RhbmNlIG9mICIzMi1iaXQuIiAo U2VlIFNlY3MgOC4xICYgOC4zKQ0KDQpTZWN0aW9uIDguMTAgTGluayBQcmVmaXgsIHBnIDE3DQo9 PT09PT09PT09PT09PT09PT09PT0NCkxhc3QgbGluZTogU2hvdWxkICJzZWNvbmRhcnkgVExWIiBi ZSAiYWRkaXRpb25hbCBUTFY/Ig0KDQpTZWN0aW9uIDkuMS4xIE11bHRpY2FzdCBMaW5rDQo9PT09 PT09PT09PT09PT09PT09PT0NClBnIDE5DQpVbmRlciBsaW5rLWlkZW50aWZpZXI6IEkgd291bGQg cHJlZmVyIHRoYXQgdGhlIGxpbmsgaWRlbnRpZmllcnMgYXJlIHVuaXF1ZSB3aXRoaW4gZWFjaCBS ZWxheS4gQSBSZWxheSBTSE9VTEQgYXNzaWduIHBlcm1hbmVudCBpZGVudGlmaWVycyBhcyBsaW5r cyBhcmUgY3JlYXRlZCwgc3RvcmVkIGluIG5vbi12b2xhdGlsZSBtZW1vcnkgb3IgZ2VuZXJhdGVk IHVzaW5nIGEgcmVwZWF0YWJsZSBhbGdvcml0aG0uIFRoZSBEaXNjb3ZlcnkgUHJveHkgY291bGQg cHJlZml4IHRoZSBsaW5rIGlkZW50aWZpZXIgd2l0aCB0aGUgUmVsYXkgbmFtZSBvciBhbiBpbnRl cm5hbCBSZWxheSBpZC4gSXQgY291bGQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgYSBUTFYgdG8gcXVl cnkgYSBSZWxheSBmb3IgYSB0YWJsZSBvZiBhbGwgdGhlIGxpbmtzIGFuZCB0aGVpciBvbi1kZXZp Y2UgZGVmaW5lZCBuYW1lcyAocHJlZmVyYWJseSBuYW1lcyB0aGF0IGNhbiBiZSBlYXNpbHkgbWFw cGVkIHRvIHBoeXNpY2FsIGludGVyZmFjZXMgYW5kL29yIGFwcGVhciBpbiBpdHMgdXNlciBpbnRl cmZhY2VzJyByZXByZXNlbnRhdGlvbiB0aGVyZW9mKSBhbmQgcG9zc2libGUgc29tZSBpbmRpY2F0 aW9uIG9mIGJhbmR3aWR0aC4gU2VlIHNlY3Rpb24gOS4xLjMsIHBnIDIyLCBsYXN0IHBhcmEgKGJl Zm9yZSA5LjIpLg0KDQpVbmRlciBoci1uYW1lOiBEb2VzICJyaWNoIHRleHQiIG1lYW4gVVRGLTg/ IChsaWtlIGluIGRyYWZ0LWlldGYtZG5zc2QtaHlicmlkLTA5LCBzZWMgNS4xLCBwZy4gOSBldGMu KQ0KDQpTZWN0aW9uIDkuMS4zIERpc2NvdmVyeSBSZWxheQ0KPT09PT09PT09PT09PT09PT09PT09 DQpwZyAyMiwgbGFzdCBwYXJhIChiZWZvcmUgOS4yKTogQWx0aG91Z2ggInRoZSBkZXRhaWxzIG9m IHRoaXMgc29ydCBvZiBjb25maWd1cmF0aW9uIGFyZSBub3Qgc3BlY2lmaWVk4oCmLCIgbWF5YmUg aXQgc2hvdWxkIGRlZmluZSBhIG1ldGhvZCB0byBleHRyYWN0IGl0cyByZXN1bHRzLiBTZWUgY29t bWVudHMgdG8gbGluay1pZGVudGlmaWVyLCBhYm92ZS4NCg0KU2VjdGlvbiA5LjIgQ29uZmlndXJh dGlvbiBGaWxlcw0KPT09PT09PT09PT09PT09PT09PT09DQpwZyAyMw0KSW4gTGlua3MgdXBzdGFp cnMtd2lmaSAmIGRvd25zdGFpcnMtd2lmaSwgc2hvdWxkICJuYW1lIiBiZSAiaHItbmFtZSI/DQoN CkZvbGxvd2luZyBteSBjb21tZW50cyB0byA5LjEuMSBsaW5rLWlkZW50aWZpZXIsIHRoZSBMaW5r IGNvbmZpZ3VyYXRpb25zIGNvdWxkIGxvb2sgbGlrZToNCkxpbmsgdXBzdGFpcnMtd2lmaQ0KICBp ZCB1cHN0YWlycy5lbjANCiAgaHItbmFtZSBVcHN0YWlycyBXaWZpDQoNCkxpbmsgdXBzdGFpcnMt d2lyZWQNCiAgaWQgdXBzdGFpcnMuZW4xDQogIGhyLW5hbWUgVXBzdGFpcnMgV2lyZWQNCg0KPT09 PT09PQ0KDQpSZWdhcmRzLA0KDQpKYW4uDQoNCg0K77u/T24gMy8xMS8xOSwgNjowMiBQTSwgImRu c3NkIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxkbnNzZC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0K DQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEV4dGVuc2lvbnMgZm9yIFNjYWxhYmxlIEROUyBTZXJ2aWNlIERpc2Nv dmVyeSBXRyBvZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6 IE11bHRpY2FzdCBETlMgRGlzY292ZXJ5IFJlbGF5DQogICAgICAgICAgICBBdXRob3JzICAgICAg ICAgOiBUZWQgTGVtb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0dWFydCBDaGVz aGlyZQ0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRuc3NkLW1kbnMtcmVsYXkt MDIudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDI5DQogICAgCURhdGUgICAgICAgICAgICA6 IDIwMTktMDMtMTENCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IGNv bXBsZW1lbnRzIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBEaXNjb3ZlcnkgUHJveHkNCiAgICAg ICBmb3IgTXVsdGljYXN0IEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeS4gIEl0IGRlc2NyaWJl cyBhDQogICAgICAgbGlnaHR3ZWlnaHQgcmVsYXkgbWVjaGFuaXNtLCBhIERpc2NvdmVyeSBSZWxh eSwgd2hpY2gsIHdoZW4gcHJlc2VudA0KICAgICAgIG9uIGEgbGluaywgYWxsb3dzIHJlbW90ZSBj bGllbnRzLCBub3QgYXR0YWNoZWQgdG8gdGhhdCBsaW5rLCB0bw0KICAgICAgIHBlcmZvcm0gbURO UyBkaXNjb3Zlcnkgb3BlcmF0aW9ucyBvbiB0aGF0IGxpbmsuDQogICAgDQogICAgDQogICAgVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbnNzZC1tZG5zLXJlbGF5 Lw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1tZG5z LXJlbGF5LTAyDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLWRuc3NkLW1kbnMtcmVsYXktMDINCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG5zc2QtbWRucy1yZWxheS0wMg0KICAgIA0KICAgIA0K ICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgZG5zc2QgbWFpbGluZyBs aXN0DQogICAgZG5zc2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Ruc3NkDQogICAgDQoNCg== From nobody Sat Mar 23 12:28: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 989CA130DCB for ; Sat, 23 Mar 2019 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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=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 6maj3dSPwRr4 for ; Sat, 23 Mar 2019 12:28:46 -0700 (PDT) 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 EFC4912AF79 for ; Sat, 23 Mar 2019 12:28:45 -0700 (PDT) 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 x2NJMAFb008934; Sat, 23 Mar 2019 12:28:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=xgqsEOokSjZpH3wmG4hOwSQfmvxN01E4We1g+PQHNqw=; b=TS9XWyw1JM6/i34uO8xWNCw062lGG64HVjpr90UlVymjGKOqQSApfNS1ovZZvE1VKhUm UeZx09EZPfdIPjAXTb64Lb2U+HTRwwPiNXrW/Xmq7qcidRVQCsWF3Z4uHTjvND/SMvou 9Ev+wrdQc11ypcA+eV2FxctYyF1QOfOz6fqk9M9Sook2FHBorc3wR0yD1hV7hOW0QOzR ytBaI2O159UxpQ7rMBBQHytxwPaoFMrZiXo/WfWBqt+pMp6dji9OYhdCGaUUchqKQAT1 wxfoeEP3aqDZyKpWPtIsb5UxZmMsGZK12Rs2s1jwIu1mEZn9tQZGBzAx4rqaNMDWkZcj 4g== Received: from crk-mtap-sz03.euro.apple.com (crk-mtap-sz03.euro.apple.com [17.66.12.163]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2rdkf3q571-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 23 Mar 2019 12:28:43 -0700 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from crk-mmpp-sz03.euro.apple.com (crk-mmpp-sz03.euro.apple.com [17.66.12.165]) by crk-mtap-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0POU0032O3FU5Z00@crk-mtap-sz03.euro.apple.com>; Sat, 23 Mar 2019 19:28:42 +0000 (GMT) Received: from process_milters-daemon.crk-mmpp-sz03.euro.apple.com by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0POU00F0026PP800@crk-mmpp-sz03.euro.apple.com>; Sat, 23 Mar 2019 19:28:42 +0000 (GMT) X-Va-A: X-Va-T-CD: 7f2b716c169c4ede4ea647ec897860de X-Va-E-CD: faf501e1ea1871e1427265464d2335a9 X-Va-R-CD: 66a0a1f6412927d5f3cfd11de372039b X-Va-CD: 0 X-Va-ID: b340782c-0495-48f3-a87d-599b5f9cdbab X-V-A: X-V-T-CD: 551bcd1897211b133062ebba42704ef7 X-V-E-CD: faf501e1ea1871e1427265464d2335a9 X-V-R-CD: 66a0a1f6412927d5f3cfd11de372039b X-V-CD: 0 X-V-ID: fbc08294-8139-4c7d-a530-70d8dcf434a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-23_09:,, signatures=0 Received: from [17.235.220.140] (unknown [17.235.220.140]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0POU00FXD3FRP710@crk-mmpp-sz03.euro.apple.com>; Sat, 23 Mar 2019 19:28:41 +0000 (GMT) Sender: cheshire@apple.com From: Stuart Cheshire In-reply-to: <4CDE2C30-BF94-4C23-8718-8ADF8650CC31@cisco.com> Date: Sat, 23 Mar 2019 20:28:03 +0100 Cc: "dnssd@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <9585C582-595A-481E-8361-38BF5337D0DD@apple.com> References: <155234648597.23114.11118112693915893825@ietfa.amsl.com> <4CDE2C30-BF94-4C23-8718-8ADF8650CC31@cisco.com> To: "Jan Komissar (jkomissa)" X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-23_09:, , signatures=0 Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-18.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: Sat, 23 Mar 2019 19:28:48 -0000 Thanks for your feedback Jan. I have updated the document as you = suggested. Stuart Cheshire On 22 Mar 2019, at 22:02, Jan Komissar (jkomissa) = wrote: > Hi, >=20 > A couple of comments: > 6.3.1 PUSH Message > Pg 22, para 3:=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In the draft: > =E2=80=A6 and names > appearing within only the RDATA of the following DNS types should be > compressed: >=20 > NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC >=20 > Suggested: > =E2=80=A6 and names > appearing within RDATA should only be compressed in/for the = following RR types : >=20 > NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC >=20 > Pg 22, para 4: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Considering that clients MUST treat PUSH messages larger than 16382 = bytes as a fatal error, I suggest changing >=20 > the change notifications SHOULD > be communicated in separate PUSH messages >=20 > to >=20 > the change notifications MUST > be communicated in separate PUSH messages >=20 > pg 33, Line 3, last word: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > "Sever" should be "Server." >=20 > Regards, >=20 > Jan. From nobody Sun Mar 24 06:12:40 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 EE30E12788C; Sun, 24 Mar 2019 06:12:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155343315291.17985.17172216198211404215@ietfa.amsl.com> Date: Sun, 24 Mar 2019 06:12:32 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-19.txt 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: Sun, 24 Mar 2019 13:12:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-19.txt Pages : 38 Date : 2019-03-24 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-19 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-19 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 24 06:14:45 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 E012712788C; Sun, 24 Mar 2019 06:14:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <155343327788.18094.6363541239716554947@ietfa.amsl.com> Date: Sun, 24 Mar 2019 06:14:37 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-hybrid-10.txt 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: Sun, 24 Mar 2019 13:14:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Discovery Proxy for Multicast DNS-Based Service Discovery Author : Stuart Cheshire Filename : draft-ietf-dnssd-hybrid-10.txt Pages : 39 Date : 2019-03-24 Abstract: This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-10 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-hybrid-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-hybrid-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 24 13:57: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 E15CB1200F5 for ; Sun, 24 Mar 2019 13:57:57 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 0nAEXXLkrrrG for ; Sun, 24 Mar 2019 13:57:55 -0700 (PDT) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 B8CC51200F1 for ; Sun, 24 Mar 2019 13:57:54 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id D1812A1300; Sun, 24 Mar 2019 21:57:52 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id dR-KfgZxohn6; Sun, 24 Mar 2019 21:57:48 +0100 (CET) From: Tim Wattenberg Content-Type: multipart/signed; boundary="Apple-Mail=_1D9A5779-76E6-4AFE-8A0C-0A15AB18251F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <92D17A70-1AC3-44C7-97C1-817536D40BD2@timwattenberg.de> Date: Sun, 24 Mar 2019 21:57:45 +0100 To: dnssd , Tom Pusateri Archived-At: Subject: [dnssd] draft-pusateri-dnsop-private-subdomains-01 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 Mar 2019 20:57:58 -0000 --Apple-Mail=_1D9A5779-76E6-4AFE-8A0C-0A15AB18251F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, I just read your draft-pusateri-dnsop-private-subdomains-01. Here=E2=80=99s some immediate feedback: General: I see to concepts in this document, one being the possibility to = register a subdomain and prevent others from (mis-)using it by = adding/changing/deleting records (Sec. 3) and one being the idea of = keeping the records private and only queryable by the owner (Sec. 4). = Having just finished reading, I=E2=80=99m not sure if I like those two = to be =E2=80=9Emixed up=E2=80=9C in one document. The first case seems = applicable to me without insisting on the second one. Sec. 3.1: I=E2=80=99d consider adding some text about FCFS being a possible = mechanism as well (not strictly necessary, but what immediately came to = my mind). What happens if "user=E2=80=9C tries to claim = "._pvt..=E2=80=9C (which is not allowed by the policy = of the administrative domain)? You might want to respond with RCODE REFUSED? I=E2=80=99m not yet convinced of using RCODE YXRRSet (instead of = REFUSED), if the zone does already exist (although this would allow a = distinction to the case described in the previous paragraph). Maybe = I=E2=80=99m just sticking a bit to heavy on what RFC 2136 says ("Some = RRset that *ought* not to exist, does exist.=E2=80=9C)...=20 I think you have a typo in "In response, appropriate NS records for = "" will be created in the "_pvtr..=E2=80=9C and [=E2=80=A6]=E2= =80=9C, or is it "_pvtr..=E2=80=9C (sic, note the r) on purpose? Sec. 3.2: "Then the message is signed with the subdomain owner's private key.=E2=80=9C= If the KEY-change is due to the private key being changed, I presume = this is *old* private key? Sec. 4.1: Just to make thinks clearer, I=E2=80=99d like an addition along the = lines "All queries *to "._pvt..=E2=80=9C* MUST be signed = with the private key of the owner.=E2=80=9C. Also I=E2=80=99d consider = allowing an unsigned query of SOA records in order to allow checking for = existence before trying to claim a subdomain. I=E2=80=99m happy to discuss your feedback on feedback =E2=80=93 here, = in the session or during the week ;-) Tim= --Apple-Mail=_1D9A5779-76E6-4AFE-8A0C-0A15AB18251F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCvYw ggToMIID0KADAgECAg5IG2oJE72AJMpdIvAU8zANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdH bG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xv YmFsU2lnbjAeFw0xNjA2MTUwMDAwMDBaFw0yNDA2MTUwMDAwMDBaMF0xCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2ln biAyIENBIC0gU0hBMjU2IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2lmiT Zf0sAexiow1Uv4vLpEORopqvsYPytW1v2fDq3M8We9cZ44QDhfnGH3CPH2xJxWkZHnCRODV+Akhd OWsYRKZqpch09F31hD5jH3FEggg+7cmn9uluJkEpgMlJuv/ZdqCjuxv2ed9LKNNKe5xRwg9lUKGf qEqd5UYEjYNP3LLIPc+YIQmYTMDxj3qpPzcmZUfYZo9JJsLDQL5mPWz/Oq0pRvATnOHy65mni8LT X1Btog5vxwaXOC9OoY5HArSDANik47pBB2Dl3Tda8gfBO6ecl2gut++pSDa86WmomapH6cf2UdL5 sSy2xUm1mJ5TU9r7cvN8D/hxPtcD+mfDAgMBAAGjggG1MIIBsTAOBgNVHQ8BAf8EBAMCAQYwagYD VR0lBGMwYQYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDCQYKKwYBBAGCNxQCAgYKKwYBBAGC NwoDBAYJKwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/ BAgwBgEB/wIBADAdBgNVHQ4EFgQUaXKCYjFnlUSFd5GAxAQ2SZ17C2EwHwYDVR0jBBgwFoAUj/BL f6guRSSuTVD6Y5qL3uLdG7wwPgYIKwYBBQUHAQEEMjAwMC4GCCsGAQUFBzABhiJodHRwOi8vb2Nz cDIuZ2xvYmFsc2lnbi5jb20vcm9vdHIzMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xv YmFsc2lnbi5jb20vcm9vdC1yMy5jcmwwZwYDVR0gBGAwXjALBgkrBgEEAaAyASgwDAYKKwYBBAGg MgEoCjBBBgkrBgEEAaAyAV8wNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j b20vcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBAKidzTLMfGfiC1DXpVxwo2biJe/qtLZT MG6HEjdcM+LCKFbjk71FlfNY2BVxTPPkgokUvv6lzEe96wZUgj7mv7716oj1ecQoIguMevYOC+Mq rkmaDpvCJ/JsthtVSgG2GeFoUHRYvBJFGE+u3l4bEzDnVSY0gKL+FIoEqweEYVIRolAAtnLgcvQR Z24TogtgCNfoFJdEO0cV5Q911vjp/kd/mvMhMYuyf0Eimg5WuBLzvw7gmd9RZCLb3IF+fvkdqOJ8 W88L66qf6txWe+ukuCws5gb/riRZf8VEfz6aFV76ZxJffGxSlzEr2r28tNW2uhT/IlSYQLg5wfl1 CxscGqMwggYGMIIE7qADAgECAgwsMCc9b7k7QCXs5fswDQYJKoZIhvcNAQELBQAwXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVy c29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMzAeFw0xOTAyMDExMjUzNDdaFw0yMjAyMDExMjUz NDdaMEwxCzAJBgNVBAYTAkRFMRcwFQYDVQQDEw5UaW0gV2F0dGVuYmVyZzEkMCIGCSqGSIb3DQEJ ARYVbWFpbEB0aW13YXR0ZW5iZXJnLmRlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 86UykfVMq6thtAjoG4Nge1JtykPwGnZySgE9yPlMIgW0OD1mFHjYVsscaYM01zPPfDDEFUs9lr2Z DJi/F8S7gMfpZCbmb4jLROvvye5nCR8FttucS3MWh4L9IcOCYd8CaG9kQSrWmfkee1RuL+Eg2OoX 0g1nNWdfCNn4bPJb4oMUH/uLQ/ME7LtGGo12fY7E+hx9sa5bCdutu5Fh2S5AwW/slE2km0WA+Om5 RtJH4G7/N07mf23BoMGr7l/mEPfv2wDAC3cfjL01OInQwgockmSqlLag0lQgGRbZQfgxbzes6Pi9 HvdKHCR4aC8e+m/9BCKp/dA+1/av93Oy0VVbDxWLgC9XPSMm/tPOXOCU5eJ0SrfoSjyOqTYY3081 frC9HvQnLhTwcRT+yJ81ARTI7xkyjObOy9k1ASO98/MBeHIRPd8A3Xrav+SXApo5BZ3ORSQ2RQxt LkT0XZGpawhTMC2j6nQwr5M9JW4Lqj81TYgz0LCI4Oivi7y8xyTomfzHOelNPzcqqsk4VuZ1oqCo cxSM+mWFspeV+oJqAbD4CrZ/un07LLGM8ULTDZjGePwPmPfOq1+DlBZULrELhxKsK2HisM1e+8+i mRBYVBSes7JkSiqANa2fjHsa9zd95k7EjXNnV+QbRBPpbJtGuHUk379Zo9NIresL6g1r4Fup1/MC AwEAAaOCAdUwggHRMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczMEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEW Jmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAkGA1UdEwQCMAAwRAYDVR0f BD0wOzA5oDegNYYzaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9nc3BlcnNvbmFsc2lnbjJzaGEy ZzMuY3JsMCAGA1UdEQQZMBeBFW1haWxAdGltd2F0dGVuYmVyZy5kZTAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFHcXvvXSu5P/V/jgMdCzOl5UnXTmMB8GA1UdIwQYMBaA FGlygmIxZ5VEhXeRgMQENkmdewthMA0GCSqGSIb3DQEBCwUAA4IBAQCvBKfotbLt/OU+bSWEho0e dViUt9R5/MaDq1a6JRwPs5S8bifSmRFFRMLVShgY3DVFeMab6qXzK7aXAWo2iCUpQrsdXr/dB4e0 VEKDWEQtv3WdYxoIoOdydajb9hLFVqhYaOzdKdDA26E62X6rC/ElOidJepsqZP1XrWA9EPvs2Z7U Ccs3Q1go7XXS9PMpYq7HPi7l6hvDUjmVULpOd6bZNEyTQYDhFKEIimDgpRDwGEOA7YdPo17RnJyG GbqcNPGoNp4ZtnptfrvZN9pqGHvlxzXQu8dMPfKQy5RK4XX7JpdMKmx5AvR0silbo7xEXhKf73jk Dks7rGKq6qb/2PahMYIEAzCCA/8CAQEwbTBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1 NiAtIEczAgwsMCc9b7k7QCXs5fswDQYJYIZIAWUDBAIBBQCgggFnMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNDIwNTc0NVowLwYJKoZIhvcNAQkEMSIEIJKJ 6Q1xQHW+lHpSTP+Xglr39FHwoLynsdeHB0APYFTXMHwGCSsGAQQBgjcQBDFvMG0wXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVy c29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMwIMLDAnPW+5O0Al7OX7MH4GCyqGSIb3DQEJEAIL MW+gbTBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMq R2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczAgwsMCc9b7k7QCXs5fsw DQYJKoZIhvcNAQEBBQAEggIARKCG94ARCsfOr0yKZAbzYd6fNZIvFgTrMPmSwAp1XFavTl+QQNBK dicG9fEmwuXpmhgEQ3FQ1PvJThfACa8J7+6FCtaCzlPAVGs8bMcOOAOr181KK1z6C1iFH3/LltpY vBD1Cfzp3mKIfWVqwXvnlgN7LHbM7bnxXckLGSeCeQi3e56oJ89DxHdi8SKDlYp6xtBjjS+/963G JZ991pOi+Q4cnaSuv7NPGy6mXcgVL+jXcF6bUIGBoBJPFFXowAlBRgbNNOOH2pMo2rS0e+R5Nb5Q q9p8PDwXhUljDeQMZPUS2Ulc2mqbP8mhieQeXUIPzoQ074zBpb420171Ldp+8mH6JzvQR+wuVgUl lIzecGwc9i5651KW7QwrwoMZnnaS2zOmUBeujpEq8PLRRuFzeEC3dKV3UHIt9rb7JaNPnYS2Tov2 DXheew+3GQ+KtWwcgT59X8If9oymJvn8tTNtikOF2ZaItfTJGGpIDbfV28fYC+wb9tmSp4q232rQ 0tg1x98qGODM4x7WtAaDolHlcx5h28k0XM63CNsQabKI3XkGxdkk0XUj0pq+uEYFz9iEZURmMKWq IbClKWFMhVDcC2IAkz7I20ZS22D7tUXeZgIVWVTuV63/rYCjb9XXl3qnUBzGR7mSqxjawPVmCxMT vKzmhYYFD6AUXpNbyts9vb0AAAAAAAA= --Apple-Mail=_1D9A5779-76E6-4AFE-8A0C-0A15AB18251F-- From nobody Mon Mar 25 15:55: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 8F8FD120148 for ; Mon, 25 Mar 2019 15:55:09 -0700 (PDT) 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 39THc73TWmwo for ; Mon, 25 Mar 2019 15:55:07 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 BEFE3120134 for ; Mon, 25 Mar 2019 15:55:07 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id 9so7107111pfj.13 for ; Mon, 25 Mar 2019 15:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pMPoahePbldRxQb2WkmL51Ui+kMIlm3XTJI+81w88xY=; b=cZRIPx752Zqqa2q17HskwGOt3aKOUSW8sB90xPkn+KIXHSsBQdnvUItLmNS/2A+OF4 Vrbyh+i3NyNewzpL/+pEm6V11l2YtYp2MOjzXOkE+a3fnDi7jqxRUoOAaKq1B9J6ZTVb W3XuTj7kfxCaKK0+9nO4l5RluUxz9jWi9NvSFQ9gq9zgpG4MFIle2ojCFHmSBVGolPym 8kKg+XUAQdKPECSsSQJYEQyP/85I1LSaAl4x0uTiAlxLJ5LFun084uzsm+2bOb32mzvm bh2EFZDcPQbDLVyxde7y9w5fbNAbMggMdDzPfUTIlaUxkHsBIyiX0aPVkfGJmR8rX4/2 j/uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pMPoahePbldRxQb2WkmL51Ui+kMIlm3XTJI+81w88xY=; b=mmwmNJTakP+VW6PToNygYJK85kwGVPkRBxbHbTVTGMURm4RB6bP7fArvsP/oBhev0z u9Kfv9QFO7Fw7P4drojLjs4GgJixQg4R9s2MMg/BZz72Twmsml34V2eZ8QWcVgcksBQZ 45pQiQy3VjBZBvPv41YQmO/UkxPJLRmGhfi39+SL2d2/9yvIYLzfI49ZX4qbtu3hwJ/d k3vY2X3EFiGhVIOqHP9NfZ+ih60iMvWTS6U9EeQ45WOxngS9ambOylID7UsAdzoquUSD ow5lmHJlb2t9Ja+KePvGe1CvpFRDSTnH68n8ZuTAgHQxiva69FZrCWAhN1mFmw4RBRDb IKmQ== X-Gm-Message-State: APjAAAU0taKB7l0yT5ZOKOF7oCTRclAk7/iY96WvtPic5TTBTdDcLAP4 DVYU1kgunmHqhGGXFnZZg/Y8DVvffY7WhKR6Z3E= X-Google-Smtp-Source: APXvYqwzwcKRRxKZxCY3WDUgeRa1enxl5Y0UFSSxf2EAxAIgQxeq5uA9C+5TYBcklWqlspMpgHvFCUxSqJghNoVTeL0= X-Received: by 2002:a65:53cb:: with SMTP id z11mr25033050pgr.139.1553554507085; Mon, 25 Mar 2019 15:55:07 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Mon, 25 Mar 2019 23:54:55 +0100 Message-ID: To: Stuart Cheshire , Christopher Wood , Christian Huitema Cc: DNSSD Content-Type: multipart/alternative; boundary="00000000000088bb630584f318dd" Archived-At: Subject: [dnssd] Private DNSSD Side-Meeting in Prague 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, 25 Mar 2019 22:55:10 -0000 --00000000000088bb630584f318dd Content-Type: text/plain; charset="UTF-8" Hi everyone, As we discussed today, we will have a side-meeting this week to discuss the details of privacy-preserving DNSSD. It will take place at the Hilton breakfast on Wednesday March 27 8-9am local time. Anyone who is planning to implement this is welcome to attend. PS: I could not find the email address for Ashu Singh, if you have it please send it to me. Thanks, David --00000000000088bb630584f318dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

As we dis= cussed today, we will have a side-meeting this week to discuss the details = of privacy-preserving DNSSD. It will take place at the Hilton breakfast on = Wednesday March 27 8-9am local time. Anyone who is planning to implement th= is is welcome to attend.

PS: I could not find the = email address for=C2=A0Ashu Singh, if you have it please send it to me.

Thanks,
David
--00000000000088bb630584f318dd-- From nobody Mon Mar 25 18:10:24 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 6064A12019A for ; Mon, 25 Mar 2019 18:10:23 -0700 (PDT) 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 4seSEBtUCweM for ; Mon, 25 Mar 2019 18:10:21 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 4E919120199 for ; Mon, 25 Mar 2019 18:10:21 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id w139so8604196oie.9 for ; Mon, 25 Mar 2019 18:10:21 -0700 (PDT) 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=+H/7UjsDiY2L0SYWBGr19ScaSel83eGk0tkvEpK9SJo=; b=a/HYxsJs1mywgUdZJAn6i2gWsMPGIfTF5HWJL4fL1CbJRiwyUYfTKs8frg/gMQVYm8 du7OLKrdiQGji+pvfterZflOg32hI+Q5kNUbFsk5/Qt0wBcN6Eh8zDy3CdoGEfNnUXol pQK6t6n/+Nmtr/HFHY2NegAGgoWChRhYofZrzYef4LquHZ75EJ/sAq7cjlk9fq/DLzit PCNszsqFHvRoOIJi8llDR7bAK7PqNImdpuzAtc39FMAtvsFrxEKEd6eoY5TyTEFbwQ+i DvuBKE4An2A2CcUhx53OYwRCgrfkOBkzxbsAaBq8RhkL0qGfqQ9UY3br3gKQeH+STTAu Kq5A== 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=+H/7UjsDiY2L0SYWBGr19ScaSel83eGk0tkvEpK9SJo=; b=NFPUtqy27gsCIBkus/1qgeR2Y7nojOdKaiIchXANPhFGWv1g6sHXdlD8oTCcRQpFi6 NIWeQlPAFdjM+hoO9WMtWJ6K3QfLlNA9xUSMPsSr64Ks/AKyyRdk28g0sBLrkO+rsVEV ZlK/HiiT7wW+U1lf3FnJsZLxxTIl9gY2dYK1nQ4A2z7y7Q3FzCGf6P/iZJNVrnfwdYgv 7rKydvj5zOSfFRFbuZiOVPbhVTO3fsm+HvZ6AF0yyIJG/BSCJAxqngF6OSc5qVNcMrGt 6EXqP0FiKpyGS6+WOsBt1/HG4M+pb5YOUDp0DqEk9QACNj9rV9CtqpIj8jEd5Bau+/iX LIvw== X-Gm-Message-State: APjAAAUNYIThNN27oPdN6lP9xlOm2E0xxIU0EEwTpLqeP7E0OHZvxR66 mDo+OOpMQFy7c1TDo3NSYijXZgOiSd/zXnp1cls= X-Google-Smtp-Source: APXvYqyAxQ9Gxx++NZCFr8mzNzdlFj23xhFwp7CzR2/UDGX3v3GvY+b2WJyqSIZ+AQc/Ah5iZgeN4S+HJ/y3HmTIgCA= X-Received: by 2002:aca:5046:: with SMTP id e67mr14128930oib.60.1553562620368; Mon, 25 Mar 2019 18:10:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ashutosh Singh Date: Mon, 25 Mar 2019 18:10:09 -0700 Message-ID: To: David Schinazi Cc: Stuart Cheshire , Christopher Wood , Christian Huitema , DNSSD Content-Type: multipart/alternative; boundary="0000000000001f9f8b0584f4fc0c" Archived-At: Subject: Re: [dnssd] Private DNSSD Side-Meeting in Prague 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 Mar 2019 01:10:23 -0000 --0000000000001f9f8b0584f4fc0c Content-Type: text/plain; charset="UTF-8" Thanks David, I got this message! I will be there for the meeting... -Ashu On Mon, Mar 25, 2019 at 3:55 PM David Schinazi wrote: > Hi everyone, > > As we discussed today, we will have a side-meeting this week to discuss > the details of privacy-preserving DNSSD. It will take place at the Hilton > breakfast on Wednesday March 27 8-9am local time. Anyone who is planning to > implement this is welcome to attend. > > PS: I could not find the email address for Ashu Singh, if you have it > please send it to me. > > Thanks, > David > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000001f9f8b0584f4fc0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks David, I got this message! I will be there for the = meeting...

-Ashu

On Mon, Mar 25, 2019 at 3:55 PM Da= vid Schinazi <dschinazi.ietf= @gmail.com> wrote:
Hi everyone,

As we discussed today, we will = have a side-meeting this week to discuss the details of privacy-preserving = DNSSD. It will take place at the Hilton breakfast on Wednesday March 27 8-9= am local time. Anyone who is planning to implement this is welcome to atten= d.

PS: I could not find the email address for=C2= =A0Ashu Singh, if you have it please send it to me.

Thanks,
David
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000001f9f8b0584f4fc0c-- From nobody Thu Mar 28 07:57:08 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 B15D912001B for ; Thu, 28 Mar 2019 07:57:06 -0700 (PDT) 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 QFBt1NF8uqCn for ; Thu, 28 Mar 2019 07:57:05 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 EF448120004 for ; Thu, 28 Mar 2019 07:57:04 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id 188so6024671pfd.8 for ; Thu, 28 Mar 2019 07:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Hvso+DgFjy+L91FBi2FIJjzrfiI5CPSAg9pI9SSAr7g=; b=czlauxMxHL6odlpWOUq1ErkxpoyvEdPVHc9iQsN7JU++eCzPaQqzgcV2667Iis7ZG3 7kx6igVZrKzcE5TzvfbQNnq+HQxEdlqpHPVQc8V4DRFrrHxveVazRTFgUErSC5F0hiiS PM9ziQ6G53+zsAn59la02QjD8RR6CEbqgoefF9d1P667YIdlBajCySSBemxErdkpsEzH JmmZniKiWmdMkbtQhegNQLOoHYhJbgmxOZtUPnmUXUwsukyXpCqaUJ4Ryg5rMabVp7rA V0twXZcvqlKz5Q9YICg8G8xlkyUfiU5zU8hjV8fyG989ehuakrD6TKaZ0OyVfb797J0I z8tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hvso+DgFjy+L91FBi2FIJjzrfiI5CPSAg9pI9SSAr7g=; b=oLx3ppb4eOR9BQQcexEatrxpNU7VPpjpCKT2fPyHikpUsfAPa4igLnYmegcSod23ri T+hnCMqwLV8qEK+NgrvsBVm1TYIKVg08w1WTQKBFG1o6JrO91lkAezxm2Bil00jVpAIe BnUkHQ7XDEjmzu5NdhyDd+Hbxoci4Oo9AeqLboHMXPC+XC8yM3n2m2gGDwYrzI7N3yEZ BT021Hg+EXhIVR+3yMjm6FE4boRfT3yZPwcukgUO00G6hvBI9O5B0dP2hfyYq1n4YtqU X5vlRywgDh7thpxWhGZbRl9DznzbQJ0iNa8B/rwDQ3SAyYo4UG7tEtQ7fEw7KQv+i91U GL3w== X-Gm-Message-State: APjAAAV8QnADxJkHnzbvuq9sTXfnD4MgXdOkzMn3pJKCavRz7qtkDtJw CgV/9Nl0/XebsAyJLuRxjXKMi+xK82wd6eMkAYYzSRZlI6w= X-Google-Smtp-Source: APXvYqzj7C9RdnncszOylCEt3cJ+P4Nkn3V7XZviDfYED7gYMvpSu8fNHl9Hl3A34vPTa0T2IijBuG3uLRnImERBZSs= X-Received: by 2002:aa7:8458:: with SMTP id r24mr7958901pfn.231.1553785024269; Thu, 28 Mar 2019 07:57:04 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Thu, 28 Mar 2019 15:56:53 +0100 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="0000000000006dd244058528c45d" Archived-At: Subject: [dnssd] Minutes Uploaded for IETF 104 Prague 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 Mar 2019 14:57:07 -0000 --0000000000006dd244058528c45d Content-Type: text/plain; charset="UTF-8" Hello everyone, We've uploaded the minutes for our meeting in Prague this week, and for the Private DNSSD design team meeting. The canonical version is here: https://datatracker.ietf.org/doc/minutes-104-dnssd/ Please review them, and let us know ASAP if you see anything wrong. Thanks, David --0000000000006dd244058528c45d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
=
We've uploaded the minutes for our meeting in Prague thi= s week,
and for the Private DNSSD design team meeting. The canoni= cal version is here:

Please review them, and let us know ASAP if y= ou see anything wrong.

Thanks,
David
--0000000000006dd244058528c45d--