From nobody Tue Oct 2 15:14:04 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE31311AE for ; Tue, 2 Oct 2018 15:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH9868bJAsbk for ; Tue, 2 Oct 2018 15:14:00 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615FB13119F for ; Tue, 2 Oct 2018 15:14:00 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Oct 2018 15:13:58 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 2 Oct 2018 15:13:58 -0700 From: Terry Manderson To: "dnssd@ietf.org" CC: "bs7652@att.com" , "dschinazi@apple.com" Thread-Topic: Placing Barbara Stark as DNSSD co-chair Thread-Index: AQHUWp02nt6uN2EM/0qzo45qrGmmng== Date: Tue, 2 Oct 2018 22:13:57 +0000 Message-ID: <10757D83-0F75-4135-8B4C-6E845B4F0DAB@icann.org> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dnssd] Placing Barbara Stark as DNSSD co-chair 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, 02 Oct 2018 22:14:02 -0000 RGVhciBETlNTRCBXRywNCg0KRmlyc3RseSwgdGhhbmsgeW91IGZvciB5b3VyIHBhdGllbmNlIHJl Z2FyZGluZyB0aGUgZ2FwIGluIEROU1NEIFdHIGxlYWRlcnNoaXAuIEkgaGF2ZSBkZWNpZGVkIHRv IHBsYWNlIEJhcmJhcmEgU3RhcmsgaW4gdGhlIEROU1NEIENvLUNoYWlyIHJvbGUsIGVmZmVjdGl2 ZSBpbW1lZGlhdGVseS4NCg0KUGxlYXNlIHdlbGNvbWUgaGVyIHRvIHRoZSBwb3NpdGlvbiBhbmQg d29yayB3aXRoIGhlciB0byBkZWxpdmVyIHRoZSBXRyBtaWxlc3RvbmVzLg0KDQpUaGFua3MgYWdh aW4gdG8gYWxsIHRoZSBvdGhlciBmb2xrcyB3aG8gcmFpc2VkIHRoZWlyIGhhbmQsIGl0IHdhc27i gJl0IGFuIGVhc3kgZGVjaXNpb24gYXMgYWxsIG9mIHRoZSBjYW5kaWRhdGVzIHdlcmUgZXhjZWxs ZW50ISBQZXJoYXBzIGEgZ29vZCBwcm9ibGVtIHRvIGhhdmUhDQoNCkFuZCBpdGVyYXRpbmcgYSBw cmV2aW91cyBlbWFpbCwgdGhhbmsgeW91IFRpbSBmb3IgYWxsIHRoZSB3b3JrIGFuZCB0aW1lIGlu dmVzdGVkIGluIEROU1NELiBCYXJiYXJhIGhhcyBiaWcgc2hvZXMgdG8gZmlsbCEhDQoNCkJhY2sg dG8geW91ciBtb3JuaW5nIGNvZmZlZSBvciBldmVuaW5nIHNpbmdsZSBtYWx0ICh0aW1lem9uZSBk ZXBlbmRlbnQpDQoNCltTZWNyZXRhcmlhdCwgQkND4oCZZDogUGxlYXNlIHJlcGxhY2UgVGltIENo b3duIHdpdGggQmFyYmFyYSBTdGFyayBhcyBETlNTRCBDby1DaGFpcl0NCg0KQ2hlZXJzDQpUZXJy eQ== From nobody Tue Oct 2 15:43:56 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF11311AE for ; Tue, 2 Oct 2018 15:43:55 -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, 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 IU6eMF7S2fTw for ; Tue, 2 Oct 2018 15:43:53 -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 98A4513119F for ; Tue, 2 Oct 2018 15:43:53 -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.22/8.16.0.22) with SMTP id w92MgdIZ034752; Tue, 2 Oct 2018 15:43:31 -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=anFYnbAriQxg1dDrtrhEZFa9BCUYX0MGJPB9ppshXhw=; b=IIPDxk5Y5LQsa3d2CZbNWwQWq+wzI4jjd6IxkNdtS9JSdIFn2q78nMnZ4bL0HjI1tgYg uAmercq3cW26VQwXuAjzVlYjwREJV46G7A2nsvXGI4s1vCNR3W9810vGeaBvXMUacv6R 8zi+ISL8/0kCIRIEEallrONTLMmdqw4TtwMtldsT5zoYkBsb5SaM2wxrPeRSUDz0EnQ9 Q0IqfDSYCMTTSBVtjQHGjRXN0CN8A3yAVXKkCAVP/YBwp/ZydbrUnH24YCPN+1NakTW+ UZAo47yIynupxv7e/SgMGQkXLiqWgjwK23nFApHS5Dj39rXyEtCCXPeYIbB0qKEhlMKq Jw== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2mt8d0cnmc-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 02 Oct 2018 15:43:31 -0700 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 mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PFZ003AVTSHVBB0@mr2-mtap-s01.rno.apple.com>; Tue, 02 Oct 2018 15:43:29 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFZ00800TI54600@nwk-mmpp-sz12.apple.com>; Tue, 02 Oct 2018 15:43:29 -0700 (PDT) X-Va-A: X-Va-T-CD: fce048f430e987f5d2b06a74bf00ad30 X-Va-E-CD: f25fe81e8f744207982661b15fc75060 X-Va-R-CD: 26cff717a373d48a3484acb55e9a42fc X-Va-CD: 0 X-Va-ID: db85efb0-6266-45e0-8901-0d918b653d48 X-V-A: X-V-T-CD: 771862c9f441b7a4b68392f2cc89d4e0 X-V-E-CD: f25fe81e8f744207982661b15fc75060 X-V-R-CD: 26cff717a373d48a3484acb55e9a42fc X-V-CD: 0 X-V-ID: 2c72d49f-d5ae-4c42-a275-6845023a1e8b Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFZ00900TMVBU00@nwk-mmpp-sz12.apple.com>; Tue, 02 Oct 2018 15:43:28 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-02_09:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.192.155.180] (unknown [17.192.155.180]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PFZ005JHTSFQLB0@nwk-mmpp-sz12.apple.com>; Tue, 02 Oct 2018 15:43:27 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <10757D83-0F75-4135-8B4C-6E845B4F0DAB@icann.org> Date: Tue, 02 Oct 2018 15:43:27 -0700 Cc: "dnssd@ietf.org" , "bs7652@att.com" Content-transfer-encoding: quoted-printable Message-id: References: <10757D83-0F75-4135-8B4C-6E845B4F0DAB@icann.org> To: Terry Manderson X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_09:, , signatures=0 Archived-At: Subject: Re: [dnssd] Placing Barbara Stark as DNSSD co-chair 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, 02 Oct 2018 22:43:55 -0000 Thanks Terry. Barbara, welcome aboard! David > On Oct 2, 2018, at 15:13, Terry Manderson = wrote: >=20 > Dear DNSSD WG, >=20 > Firstly, thank you for your patience regarding the gap in DNSSD WG = leadership. I have decided to place Barbara Stark in the DNSSD Co-Chair = role, effective immediately. >=20 > Please welcome her to the position and work with her to deliver the WG = milestones. >=20 > Thanks again to all the other folks who raised their hand, it wasn=E2=80= =99t an easy decision as all of the candidates were excellent! Perhaps a = good problem to have! >=20 > And iterating a previous email, thank you Tim for all the work and = time invested in DNSSD. Barbara has big shoes to fill!! >=20 > Back to your morning coffee or evening single malt (timezone = dependent) >=20 > [Secretariat, BCC=E2=80=99d: Please replace Tim Chown with Barbara = Stark as DNSSD Co-Chair] >=20 > Cheers > Terry From nobody Wed Oct 3 02:37:25 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8A131197; Wed, 3 Oct 2018 02:37: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, 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 RdMQSgdLSY5J; Wed, 3 Oct 2018 02:37:21 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38665131211; Wed, 3 Oct 2018 02:37:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DFE01419ED; Wed, 3 Oct 2018 11:37:18 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BEB0657; Wed, 3 Oct 2018 11:37:17 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6656F5B; Wed, 3 Oct 2018 11:37:17 +0200 (CEST) Received: (nullmailer pid 12101 invoked by uid 1000); Wed, 03 Oct 2018 09:37:17 -0000 Date: Wed, 3 Oct 2018 11:37:16 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Hauke Petersen , Peter van der Stok , Jim Schaad Cc: core@ietf.org, dnssd@ietf.org Message-ID: <20181003093716.GA9366@hephaistos.amsuess.com> References: <20180926161903.GA30204@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20180926161903.GA30204@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [dnssd] Second Resource Directory plug test 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, 03 Oct 2018 09:37:25 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello RD plug test participants and watching mailing lists, these are the promised details about the upcoming second RD interoperability event. A -15 version of Resource Directory was just published[1] and will be the reference draft; it contains no changes to actual mechanisms compared to -14. The tests we will run through are described at [2]. The plug test will take place online, using the Jitsi at [3], which provides screen sharing and a common note taking area. As no time was found for all participants to meet, we'll hold the event in two time slots: 2018-10-10 at 10:00 CEST (08:00 UTC) and 2018-10-12 at 16:00 CEST (14:00 UTC, 07:00 MST). Participants who did not register in the schedule sent with the original mail are asked to contact me directly for further planning. See you there Christian [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-15 [2]: http://htmlpreview.github.io/?https://github.com/core-wg/resource-dire= ctory/draft-ietf-core-resource-directory-15/interop-spec.html [3]: https://jitsi.tools.ietf.org/resource-directory-interop-2 --=20 There's always a bigger fish. -- Qui-Gon Jinn --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlu0jckACgkQOY0REtOk veGCuBAAqwHMiPJJDlVtxAvtkhPfvFf1mFRic9KlnytwZFCPtlNhDhIgy1Bd1Nwu Vmhdswi8DrHPLauraM9eiLUX311MGDES//HsSA+tYTnIQIVxUnVrIT+KmWjxGANh VhY99gfDeC2ULTh4eekRjTC9adPXKkV+hflS3Y1O/8ikeceAZJz+FZ52XTx3I8rX +WZ8bSrTAyxgt6CeEw1zUIgclloEKbGRERvyE6iXO8bY3/poQqQPI1pcqnokSwrp 0JRvEOqUtW6GHuxWzN8VmWrfiMvPWLYwXVMs1i0zGhyO9CGfrd1S2lP/tZj4ubK6 7sXsr6VFr+MwVVfmFPBkJgFH4f2plDXjLadiAmWTy4cGJQHgrgq7zuqv+DMcnUpr a0a+pvybW2GbI5vp4SpQUDJz7WauxJ9pHF9jrfnF5xPupAbKo6sKT8YBuJnqD4Wr x3GW8+ibUzaCjtK/3pnhTG60mBmfBzac7iI9DPUuJ0htHTOTkiYms5AtKyCggKw0 Z5zblNErjZJrmuAYvux1PbwgkL/Fv0pZydcwbjtNdlpRXvwEAwV2jElTzGtJBcFY zCP4wcRGnr2PRJQOQu9PhvPkJ01WU6lEOd/QLVxKQPREvF/BO0eIIFfgtloqI9Gx Dzy6zslMLOcb+NMXxXBgZ48Hl6LmPaRniyI2AmHqd4MutDqKhHk= =dRRR -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From nobody Mon Oct 15 05:54:11 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF7130E4D for ; Mon, 15 Oct 2018 05:54:09 -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, KHOP_DYNAMIC=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 I7FM59VCHJC8 for ; Mon, 15 Oct 2018 05:54:07 -0700 (PDT) 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 B4402130E63 for ; Mon, 15 Oct 2018 05:54:07 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9FCjWM1007081 for ; Mon, 15 Oct 2018 08:54:07 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2n4q9nrmeu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Oct 2018 08:54:07 -0400 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 w9FCs6l7027052 for ; Mon, 15 Oct 2018 08:54:06 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9FCs2Bo027004 for ; Mon, 15 Oct 2018 08:54:02 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 1EF4C40002B6 for ; Mon, 15 Oct 2018 12:54:02 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30488.vci.att.com (Service) with ESMTPS id 0F2B740002B0 for ; Mon, 15 Oct 2018 12:54:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.143]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0415.000; Mon, 15 Oct 2018 08:54:01 -0400 From: "STARK, BARBARA H" To: "dnssd@ietf.org" Thread-Topic: dnssd scheduling Thread-Index: AdRkgnObBZYjmc6HRdKLi2izveaeFQ== Date: Mon, 15 Oct 2018 12:54:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DEEFA05@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.251.10] 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=2018-10-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810150118 Archived-At: Subject: [dnssd] dnssd scheduling 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, 15 Oct 2018 12:54:09 -0000 Hi dnssd, Dnssd WG is currently scheduled to meet in Bangkok November 8 at 13:50-15:2= 0 (Thursday Afternoon session I). Important dates between now and then: Document submission deadline: Monday, October 22 Please provide agenda requests. We need to have draft WG agendas by Wednesd= ay Oct 24. Daylight saving time ends in some Middle East countries: Friday, October 26 Daylight saving time ends in parts of Europe, Antarctica, Mexico: Sunday, O= ctober 28 Daylight saving time ends in parts of US, Canada, Mexico (different parts):= Sunday, November 4 [I just thought the time changes were useful info.] Other: Does anyone want to present with Meetecho? Get those expiring drafts updated! I hope to see many of you in Bangkok! Barbara From nobody Mon Oct 15 21:01:15 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7D7127333; Mon, 15 Oct 2018 21:01: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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <153966246245.2822.6096519727074935658@ietfa.amsl.com> Date: Mon, 15 Oct 2018 21:01:02 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-05.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: Tue, 16 Oct 2018 04:01:03 -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 : Privacy Extensions for DNS-SD Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-privacy-05.txt Pages : 21 Date : 2018-10-15 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 a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. Revisions of this draft are currently considered in the DNSSD working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-privacy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-privacy-05 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-privacy-05 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 Oct 15 21:22:39 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B71A0128CB7; Mon, 15 Oct 2018 21:22:30 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <153966375070.3449.3599682783734611989@ietfa.amsl.com> Date: Mon, 15 Oct 2018 21:22:30 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-pairing-05.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: Tue, 16 Oct 2018 04:22:31 -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 : Device Pairing Using Short Authentication Strings Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-pairing-05.txt Pages : 11 Date : 2018-10-15 Abstract: This document proposes a device pairing mechanism that establishes a relation between two devices by agreeing on a secret and manually verifying the secret's authenticity using an SAS (short authentication string). Pairing has to be performed only once per pair of devices, as for a re-discovery at any later point in time, the exchanged secret can be used for mutual authentication. The proposed pairing method is suited for each application area where human operated devices need to establish a relation that allows configurationless and privacy preserving re-discovery at any later point in time. Since privacy preserving applications are the main suitors, we especially care about privacy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-pairing-05 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-pairing-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-pairing-05 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 Wed Oct 17 00:47:31 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B761130E80; Wed, 17 Oct 2018 00:47:29 -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, 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 GRQPmJpmtIyo; Wed, 17 Oct 2018 00:47:26 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9202212D4E9; Wed, 17 Oct 2018 00:47:25 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 44F1441B67; Wed, 17 Oct 2018 09:47:22 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F3AAC2A; Wed, 17 Oct 2018 09:47:20 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8747343; Wed, 17 Oct 2018 09:47:20 +0200 (CEST) Received: (nullmailer pid 3562 invoked by uid 1000); Wed, 17 Oct 2018 07:47:19 -0000 Date: Wed, 17 Oct 2018 09:47:19 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org, dnssd@ietf.org Message-ID: <20181017074719.GA1873@hephaistos.amsuess.com> References: <20180926161903.GA30204@hephaistos.amsuess.com> <20181003093716.GA9366@hephaistos.amsuess.com> <20181010112030.GC31858@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20181010112030.GC31858@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [dnssd] Second Resource Directory plug test: Report, part II 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, 17 Oct 2018 07:47:29 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello observers of the Resource Directory plug tests, we have concluded part II of the second installment of the RD plug tests. (DNS-SD: Report part I only went to CoRE as it was time critical to an interim. The summary covers both, details on [1].) Summary: Three implementations were tested, and all eventually passed the implemented subsets of RD. (Jim's covered everything, Christian's everything but groups, Hauke's embedded one acted as an endpoint). Four details that need claraification in the specification were discovered (handling of link-local addresses, and the below), but nothing major. Two implementations could not interoperate due to IPv6 not having been universally deployed. No implementations of extensions to RD (like RD-DNS-SD) were known so none were tested. We hope for participation of implementing parties in future events. Questions raised: * When matching against endpoint registrations, can an href filter query be matched as a relative reference (eg. /lkp/ep?href=3D/reg/1)? * Can a registration be "taken over" by a Commissioning Tool? * Is displaying the base of a registration mandated in EP lookup? They're being taken up in the document's issue tracker for discussion among the authors, and expected to be clarified in the next version of the draft. Details below. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/enMOFPTiK9qcS-lxpQ-VVyyKbuc --- =20 Implementations under test were: * Jim Schaad's resource directory, implemented in C# and running on an unconstrained system. * aiocoap's resource directory (see [1]; Christian) * RIOT's registrant endpoint (see [1]; Hauke) Test execution: * Christian's server with Jim's registrant and lookup client Tests were executed in sequence and passed unless noted otherwise, with the following alterations and notes: * Test 1, 2: Unicast address used as devices were not in multicast range. * Tests 6-7, 9 and 14 (anything group related) were not supported by the server * Test 11 was not implemented on the server. * Bugs in the implementations were found in tests 1 (when modified by the client to include ct lookup; actually a bug in the server's implementation of RFC6690), 13 (client sent content-format indication payload while it shouldn't, due to a limitation of the underlying library). * Jim's server with Hauke's client * Test could not be executed because the test sites did not share a common IP version. * Registration through a relay (see rd-relay description in [1]) was attempted but failed for reasons discovered later. The paring will be tried again in the next plug test, either with IPv6 everywhere or some sort of tunneling in place, possibly facilitated by F-Interop. * Jim's server with Christian's client Tests were executed out of sequence because several tests are grouped together in a single client application run. All tests except where noted did pass, with several alterations and notes: * Test 1, 2: Unicast address used as devices were not in multicast range. * Tests 6-7, 9 and 14 (anything group related) were not supported by the client. * The .well-known/core resource was advertised in all registrations in addition to the prescribed resources, and consequently shown in the lookups. * In test 13, the wrong registration was updated. This was noticed in test 15; the lookup results were consequently in conflict with the test description, but consistent with the course of the experiment. * Bugs were found in tests 2 (the * in lookup was matched to "one or more characters", actually a bug in the server's implementation of RFC6690) and 4 (a slash was expected to trail the base value), and fixed before continuing. * The participants spent some time debugging the spurious absence of GET requests triggered by simple registration, which was actually an artifact of all network scanners having been configured to port 5683 exclusively, and the registrant using a different port to avoid collision with an already active non-simple endpoint. --=20 There's always a bigger fish. -- Qui-Gon Jinn --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvG6QQACgkQOY0REtOk veE9dBAAygKAbl123tapbHwsb3C+T5abNUrVGSA5siX7+EGxbrtHBryiA2zC4+xK 6eQm8vzEQg1EMHURScMB0sXs8a03vzcOPI9cJnzkN7qW1qPiTD8yAErxzWQKAYIa jotl6DIr+xWvrWJ1NaEjrila7x0PydIG4GyCVW+8z/d7uQThZzmfBu26Hg707EE5 5r83or2emqHxanV4oa78kBRLdjyRh6djKO6BkLy5HR9fC3dyGyV6YbpRf2MdFhrH RFYC9pMJGYv0bcMefQFhfd8eCf4H3GvP7uLT14UHXJygbHwxK5sY2B82iQiyYNre iFmctTELKa9oD6N0V8ldP14iJB15d5waradJdA9S2oQ8y9AIbTJXV0OVf2btb6eF nYHBWGOEuX3k8EtTqJpcpQnF1WrMXM/TszNfrxpBQcS//HAVn5fvNZlOTDhS9IR+ oUETEE8xnQ5beHbKpQAZ47UDZq6VIwVoWJBr6Ljsi0U45M+HINuBPgOYMvH8yUQQ RylojLxYkt/vj2aLgkt1cgx3Rn5cNdJQk7iMkIwO9l9C+pg/Wam+oBOjJr3dVj1v stXPWKoVVjwhaDGJreUHi3qopH/RJfoVSH2wIvG1tftG7xSk2HYPOtvQ/cSsP4De 6L6S+HKIuyWAaFpUNpLZ4v5RRfhOD2N7+783pNK6FGsT72zkzcs= =SZO6 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From nobody Fri Oct 19 12:03:22 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB43131064; Fri, 19 Oct 2018 11:56:39 -0700 (PDT) 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.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539982.6592.4555353876953881913.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:39 -0700 Archived-At: Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 103 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, 19 Oct 2018 18:56:48 -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) Thursday, 8 November 2018, Afternoon Session I 1350-1550 Room Name: Meeting 2 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/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 v6ops core anima Second Priority: ipsecme intarea mls babel People who must be present: Tim Chown Terry Manderson David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 20 04:48:58 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01C128BAC for ; Sat, 20 Oct 2018 04:48:56 -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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rUx2CYQsaZj for ; Sat, 20 Oct 2018 04:48:54 -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 F0C51126BED for ; Sat, 20 Oct 2018 04:48:53 -0700 (PDT) Received: from [172.20.1.27] (50-204-242-86-static.hfc.comcastbusiness.net [50.204.242.86]) (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 CEE0721C6A; Sat, 20 Oct 2018 07:48:52 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-558E0D05-BD89-45CE-B904-58F561F6F9CD Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16A404) In-Reply-To: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> Date: Sat, 20 Oct 2018 07:48:51 -0400 Cc: dnssd , Stuart Cheshire , Tim Wicinski Content-Transfer-Encoding: 7bit Message-Id: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> To: David Schinazi Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 20 Oct 2018 11:48:56 -0000 --Apple-Mail-558E0D05-BD89-45CE-B904-58F561F6F9CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This last call deadline is approaching and there hasn=E2=80=99t been much fe= edback. That is probably due to the fact that we=E2=80=99ve been through las= t call before.=20 But in order to be thorough, even if you responded before, if you think this= document is ready, please just send a short affirmation before the 22 Octob= er deadline.=20 Thanks, Tom > On Sep 29, 2018, at 8:26 PM, David Schinazi wrote: >=20 > Hi everyone, >=20 > This email starts a three-week working group last call for draft-ietf-dnss= d-push. The call will run until October 22nd. > Please review this draft and send comments to the list, even if only to sa= y you support the draft. >=20 > The authors have let us know that the draft was updated to reflect the fin= al changes in DNS Stateful Operations (draft-ietf-dnsop-session-signal) whic= h was submitted to the IESG for publication. If we get enough support on the= list for this document, we will be able to progress it alongside the Discov= ery Proxy (draft-ietf-dnssd-hybrid). >=20 > The chairs would also like to hear about implementation experience. >=20 > Thanks, > David --Apple-Mail-558E0D05-BD89-45CE-B904-58F561F6F9CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thi= s last call deadline is approaching and there hasn=E2=80=99t been much feedb= ack. That is probably due to the fact that we=E2=80=99ve been through last c= all before. 

But in or= der to be thorough, even if you responded before, if you think this document= is ready, please just send a short affirmation before the 22 October deadli= ne. 

Thanks,
Tom

On Sep 29, 2018, at 8:26 PM, Davi= d Schinazi <dschinazi@apple.com> wrote:

Hi ever= yone,

This email starts a three-week working gr= oup last call for draft-ietf-dnssd-push. The call will run until O= ctober 22nd.
Please review this draft and send comments to the= list, even if only to say you support the draft.

The authors have let us know that the draft was upd= ated to reflect the final changes in DNS Stateful Operations (draft-iet= f-dnsop-session-signal) which was submitted to the IESG for publication. If w= e get enough support on the list for this document, we will be able to progr= ess it alongside the Discovery Proxy (draft-ietf-dnssd-hybrid).

The chairs would also like t= o hear about implementation experience.

= Thanks,
David
= --Apple-Mail-558E0D05-BD89-45CE-B904-58F561F6F9CD-- From nobody Mon Oct 22 07:00:12 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0A12D4E8 for ; Mon, 22 Oct 2018 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.601 X-Spam-Level: X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-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, 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 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 m4ehN_gN9IwF for ; Mon, 22 Oct 2018 07:00:00 -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 4DFB7130E48 for ; Mon, 22 Oct 2018 06:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8786; q=dns/txt; s=iport; t=1540216775; x=1541426375; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VVAQkDMowM7e8Y5z5+m95SX+zegF3UN5umD9k5lwNfA=; b=WZGEzUMF61u0xdNXFGgFfYDoLn6gKE1RRU9egf1GxvtS8cL4S2nSKK9N icQpd9VuwBPhMGQSnv0wp0oV+HVhEWHPRwD9UHaniplMijGklDXRmHy7A BaHdkYnHk47W6AlQi/GIvk29YONpuuxQ+XnvVLYaYKsHq1QVztYhRmnyC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACe1s1b/5xdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMGoINiHqIU4VIFIF?= =?us-ascii?q?mCwEBIwmEQAIXhH4hNA0NAQMBAQIBAQJtHAyFOgEBAQEDHQZWEAIBCBEDAQI?= =?us-ascii?q?oAwICAh8RFAkIAgQBDQWDIQGBHUwDFQ+kb4EuhTuCNw2CEwWLUheBQT+BESc?= =?us-ascii?q?fgkyCVkUBAQOBKwESAT8Wgk0xgiYCjjWGEolTLgkChmCDHYNPgyQXgVKEc4h?= =?us-ascii?q?BgSiMWHiIZgIRFIEmHThkcXAVOyoBgkGLGYU+b4EoiCCBHwGBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,412,1534809600"; d="scan'208,217";a="189125967" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 13:59:31 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9MDxVtM016739 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2018 13:59:31 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 08:59:30 -0500 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 08:59:30 -0500 From: "Jan Komissar (jkomissa)" To: Tom Pusateri , David Schinazi CC: Stuart Cheshire , Tim Wicinski , dnssd Thread-Topic: [dnssd] Working group last call for draft-ietf-dnssd-push Thread-Index: AQHUWFROXVpV2MKdXUmWQfXaA3KbEKUoeOaAgAMGG4A= Date: Mon, 22 Oct 2018 13:59:30 +0000 Message-ID: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.100] Content-Type: multipart/alternative; boundary="_000_C4802C62E94C48AE867F9A4743A4AEA2ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.29, xch-rcd-019.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 22 Oct 2018 14:00:08 -0000 --_000_C4802C62E94C48AE867F9A4743A4AEA2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhcHByb3ZlLg0KDQpKYW4uDQoNCkZyb206IGRuc3NkIDxkbnNzZC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgVG9tIFB1c2F0ZXJpIDxwdXNhdGVyaUBiYW5nai5jb20+DQpEYXRlOiBT YXR1cmRheSwgT2N0b2JlciAyMCwgMjAxOCBhdCA3OjQ5IEFNDQpUbzogRGF2aWQgU2NoaW5hemkg PGRzY2hpbmF6aUBhcHBsZS5jb20+DQpDYzogU3R1YXJ0IENoZXNoaXJlIDxjaGVzaGlyZUBhcHBs ZS5jb20+LCBUaW0gV2ljaW5za2kgPHRqdy5pZXRmQGdtYWlsLmNvbT4sIGRuc3NkIDxkbnNzZEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZG5zc2RdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZv ciBkcmFmdC1pZXRmLWRuc3NkLXB1c2gNCg0KVGhpcyBsYXN0IGNhbGwgZGVhZGxpbmUgaXMgYXBw cm9hY2hpbmcgYW5kIHRoZXJlIGhhc27igJl0IGJlZW4gbXVjaCBmZWVkYmFjay4gVGhhdCBpcyBw cm9iYWJseSBkdWUgdG8gdGhlIGZhY3QgdGhhdCB3ZeKAmXZlIGJlZW4gdGhyb3VnaCBsYXN0IGNh bGwgYmVmb3JlLg0KDQpCdXQgaW4gb3JkZXIgdG8gYmUgdGhvcm91Z2gsIGV2ZW4gaWYgeW91IHJl c3BvbmRlZCBiZWZvcmUsIGlmIHlvdSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5LCBwbGVh c2UganVzdCBzZW5kIGEgc2hvcnQgYWZmaXJtYXRpb24gYmVmb3JlIHRoZSAyMiBPY3RvYmVyIGRl YWRsaW5lLg0KDQpUaGFua3MsDQpUb20NCg0KT24gU2VwIDI5LCAyMDE4LCBhdCA4OjI2IFBNLCBE YXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNvbTxtYWlsdG86ZHNjaGluYXppQGFwcGxl LmNvbT4+IHdyb3RlOg0KSGkgZXZlcnlvbmUsDQoNClRoaXMgZW1haWwgc3RhcnRzIGEgdGhyZWUt d2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXB1c2g+LiBUaGUgY2Fs bCB3aWxsIHJ1biB1bnRpbCBPY3RvYmVyIDIybmQuDQpQbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQg YW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QsIGV2ZW4gaWYgb25seSB0byBzYXkgeW91IHN1 cHBvcnQgdGhlIGRyYWZ0Lg0KDQpUaGUgYXV0aG9ycyBoYXZlIGxldCB1cyBrbm93IHRoYXQgdGhl IGRyYWZ0IHdhcyB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIGZpbmFsIGNoYW5nZXMgaW4gRE5TIFN0 YXRlZnVsIE9wZXJhdGlvbnMgKGRyYWZ0LWlldGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwpIHdoaWNo IHdhcyBzdWJtaXR0ZWQgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uLiBJZiB3ZSBnZXQgZW5v dWdoIHN1cHBvcnQgb24gdGhlIGxpc3QgZm9yIHRoaXMgZG9jdW1lbnQsIHdlIHdpbGwgYmUgYWJs ZSB0byBwcm9ncmVzcyBpdCBhbG9uZ3NpZGUgdGhlIERpc2NvdmVyeSBQcm94eSAoZHJhZnQtaWV0 Zi1kbnNzZC1oeWJyaWQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5z c2QtaHlicmlkPikuDQoNClRoZSBjaGFpcnMgd291bGQgYWxzbyBsaWtlIHRvIGhlYXIgYWJvdXQg aW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZS4NCg0KVGhhbmtzLA0KRGF2aWQNCg== --_000_C4802C62E94C48AE867F9A4743A4AEA2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <69A77A456CE04D4BAC331A76F215848A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYXBwcm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFuLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ZG5zc2QgJmx0O2Ruc3NkLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBUb20gUHVzYXRlcmkgJmx0O3B1c2F0ZXJpQGJh bmdqLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJkYXksIE9jdG9iZXIgMjAsIDIwMTgg YXQgNzo0OSBBTTxicj4NCjxiPlRvOiA8L2I+RGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aUBh cHBsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5TdHVhcnQgQ2hlc2hpcmUgJmx0O2NoZXNoaXJl QGFwcGxlLmNvbSZndDssIFRpbSBXaWNpbnNraSAmbHQ7dGp3LmlldGZAZ21haWwuY29tJmd0Oywg ZG5zc2QgJmx0O2Ruc3NkQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2Ru c3NkXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGxhc3QgY2FsbCBkZWFkbGluZSBpcyBhcHByb2FjaGluZyBhbmQgdGhlcmUgaGFzbuKA mXQgYmVlbiBtdWNoIGZlZWRiYWNrLiBUaGF0IGlzIHByb2JhYmx5IGR1ZSB0byB0aGUgZmFjdCB0 aGF0IHdl4oCZdmUgYmVlbiB0aHJvdWdoIGxhc3QgY2FsbCBiZWZvcmUuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBpbiBvcmRl ciB0byBiZSB0aG9yb3VnaCwgZXZlbiBpZiB5b3UgcmVzcG9uZGVkIGJlZm9yZSwgaWYgeW91IHRo aW5rIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHksIHBsZWFzZSBqdXN0IHNlbmQgYSBzaG9ydCBhZmZp cm1hdGlvbiBiZWZvcmUgdGhlIDIyIE9jdG9iZXIgZGVhZGxpbmUuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBTZXAgMjksIDIwMTgsIGF0IDg6MjYgUE0sIERhdmlk IFNjaGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppQGFwcGxlLmNvbSI+ZHNjaGlu YXppQGFwcGxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBldmVyeW9uZSw8YnI+DQo8YnI+DQpUaGlzIGVt YWlsIHN0YXJ0cyBhIHRocmVlLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcHVz aCI+ZHJhZnQtaWV0Zi1kbnNzZC1wdXNoPC9hPi4mbmJzcDtUaGUgY2FsbCB3aWxsIHJ1biB1bnRp bCBPY3RvYmVyIDIybmQuPGJyPg0KUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IGFuZCBzZW5kIGNv bW1lbnRzIHRvIHRoZSBsaXN0LCBldmVuIGlmIG9ubHkgdG8gc2F5IHlvdSBzdXBwb3J0IHRoZSBk cmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGF1dGhvcnMgaGF2ZSBsZXQgdXMga25vdyB0aGF0IHRoZSBkcmFmdCB3YXMgdXBkYXRlZCB0byBy ZWZsZWN0IHRoZSBmaW5hbCBjaGFuZ2VzIGluJm5ic3A7RE5TIFN0YXRlZnVsIE9wZXJhdGlvbnMg KGRyYWZ0LWlldGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwpIHdoaWNoIHdhcyBzdWJtaXR0ZWQgdG8g dGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uLiBJZiB3ZSBnZXQgZW5vdWdoIHN1cHBvcnQgb24gdGhl IGxpc3QgZm9yDQogdGhpcyBkb2N1bWVudCwgd2Ugd2lsbCBiZSBhYmxlIHRvIHByb2dyZXNzIGl0 IGFsb25nc2lkZSB0aGUgRGlzY292ZXJ5IFByb3h5ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1oeWJyaWQiPmRyYWZ0LWlldGYtZG5zc2QtaHli cmlkPC9hPikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBjaGFpcnMgd291bGQgYWxzbyBsaWtlIHRvIGhlYXIgYWJvdXQgaW1wbGVtZW50 YXRpb24gZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NClRoYW5rcyw8YnI+DQpEYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C4802C62E94C48AE867F9A4743A4AEA2ciscocom_-- From nobody Mon Oct 22 16:45:30 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3F130EBC; Mon, 22 Oct 2018 16:45:21 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <154025192109.13900.7249458333812878836@ietfa.amsl.com> Date: Mon, 22 Oct 2018 16:45:21 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-cheshire-dnssd-roadmap-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, 22 Oct 2018 23:45:29 -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 Discovery Road Map Author : Stuart Cheshire Filename : draft-cheshire-dnssd-roadmap-02.txt Pages : 20 Date : 2018-10-22 Abstract: Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cheshire-dnssd-roadmap/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-cheshire-dnssd-roadmap-02 https://datatracker.ietf.org/doc/html/draft-cheshire-dnssd-roadmap-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-cheshire-dnssd-roadmap-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 Tue Oct 23 00:41:33 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B099130DDB; Tue, 23 Oct 2018 00:41: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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <154028049219.31377.3515587968407587654@ietfa.amsl.com> Date: Tue, 23 Oct 2018 00:41:32 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-pairing-info-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: Tue, 23 Oct 2018 07:41:32 -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 : Device Pairing Design Issues Authors : Daniel Kaiser Christian Huitema Filename : draft-ietf-dnssd-pairing-info-02.txt Pages : 17 Date : 2018-10-23 Abstract: This document discusses issues and problems occuring in the design of device pairing mechanism. It presents experience with existing pairing systems and general user interaction requirements to make the case for "short authentication strings". It then reviews the design of cryptographic algorithms designed to maximise the robustness of the short authentication string mechanisms, as well as implementation considerations such as integration with TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-pairing-info-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-pairing-info-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-pairing-info-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 Tue Oct 23 08:49:08 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 202BC130E4E; Tue, 23 Oct 2018 08:49:01 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <154030974108.31401.380315367024024351@ietfa.amsl.com> Date: Tue, 23 Oct 2018 08:49:01 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.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: Tue, 23 Oct 2018 15:49:01 -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-00.txt Pages : 19 Date : 2018-10-23 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 eliminates the dependency on Multicast DNS as the foundation layer, 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 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 Tue Oct 23 15:49:12 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F046130DD5; Tue, 23 Oct 2018 15:49:04 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <154033494461.31349.9815881989522835095@ietfa.amsl.com> Date: Tue, 23 Oct 2018 15:49:04 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-cheshire-dnssd-roadmap-03.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: Tue, 23 Oct 2018 22:49:05 -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 Discovery Road Map Author : Stuart Cheshire Filename : draft-cheshire-dnssd-roadmap-03.txt Pages : 20 Date : 2018-10-23 Abstract: Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cheshire-dnssd-roadmap/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-cheshire-dnssd-roadmap-03 https://datatracker.ietf.org/doc/html/draft-cheshire-dnssd-roadmap-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-cheshire-dnssd-roadmap-03 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 Tue Oct 23 18:15:08 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A97E130DC6 for ; Tue, 23 Oct 2018 18:15:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdt7QgIw7HgB for ; Tue, 23 Oct 2018 18:15:04 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 28AFE128CE4 for ; Tue, 23 Oct 2018 18:15:04 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id e17-v6so2727728oib.4 for ; Tue, 23 Oct 2018 18:15:04 -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; bh=aheBaNuvYNW0lnEfSlwaoHPqPdrVgsXI6eAgG5vy4JE=; b=KTBeh9VlcijtsSjwV5VPTNLBlb3x3cDtuLU3DrTU+sMZ9RRGSy01LsQb7Q9BGuURsl S31e4nVjNqTK4wjBkAkEYpesuRJysFbe2uHUq6Qn1UwCMXMMBeLN+Rz8yGquYeG5L1X8 ewl/st7iWo2BskJfK53VCEmr/aAYvz9zf9+aIdGFyyl3GVHPJElyhVxV/ZiQZnK4aOEZ MhtZ6b2kJbzp2HYbLbtFNd2wPlFLuSTBMrRrcHbBcvK2U9cxZeUouvj6EuzOpQGpZVCJ nT0f66sthcU9br1tYKydKT0vkxLiN53m09PG5JJbXjVNt1sAYvP9EcNE3ATRjX8CWQPu h5lg== 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; bh=aheBaNuvYNW0lnEfSlwaoHPqPdrVgsXI6eAgG5vy4JE=; b=TezBjjpd4O7bdNvHizc7mqx/Oa8JpIUyYLTpfN6HdQM/QdRXXI3q3eUygV3cxeHVrK EdT0JYMV7CQggANPsc7+DwhJtkc2OH/OjSulmTkPxlL0OYpCdtLZRne6H/nelq4QMJjw uFo62ewrPNH8TEXQ61sJ/0bycxRStXRKuiPhX5qfKMxrxGsZmHAWl3RJen3uql0u/lb4 uB1FbQcSqZF2FlX98/NBNfFLgG8XpiOKl+Ph8Ayl3JXRQZxYMrp41RKR3ngvagNbpPHK 9Pqq9AbQDfMFDSEMDsU+3Pma1eCIduF/voBcSzydWsNwA1y6lk6HXI4lWEVzpXmNW3uE ilQw== X-Gm-Message-State: AGRZ1gKkNIRHrFrahem+NIMpa1HUcg0ZA0yBPGZJwfKK9BuLv6M9KYGB K8fwKriiq3N5n4eX6MZwsEbg0+W35vrqZ2LVzOeQGJmQOiE= X-Google-Smtp-Source: AJdET5cJFEdV2n6IlhTLzSQligBDjyiXcdne7SYvCPOPNio4GV3aAweIY9laNUNgEQIbuYKUQ/uyeG/vuSZpMBiRhqc= X-Received: by 2002:aca:5452:: with SMTP id i79-v6mr311779oib.344.1540343703231; Tue, 23 Oct 2018 18:15:03 -0700 (PDT) MIME-Version: 1.0 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> In-Reply-To: <154030974108.31401.380315367024024351@ietfa.amsl.com> From: Martin Thomson Date: Wed, 24 Oct 2018 12:14:54 +1100 Message-ID: To: dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:15:07 -0000 For a moment, I thought that this was SRP-related: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol TLA-exhaustion is a think apparently. On Wed, Oct 24, 2018 at 2:49 AM wrote: > > > 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-00.txt > Pages : 19 > Date : 2018-10-23 > > 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 eliminates the dependency > on Multicast DNS as the foundation layer, 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-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 > > > 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/ > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Oct 23 18:18:36 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31F6128CE4 for ; Tue, 23 Oct 2018 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 OE4Cm5fE_c9a for ; Tue, 23 Oct 2018 18:18:32 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 CBDF112F1A6 for ; Tue, 23 Oct 2018 18:18:31 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id d14-v6so3929352qto.4 for ; Tue, 23 Oct 2018 18:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wIbTKgHQucXGP2CcMT3BAsfQblK0W1kTyDVo7A8HY/8=; b=y4oniLmEeVpKJ4CxQQOBJ7lqd+2hfut5LF8zxel826ps8GqA9MyiD36TSukitIpZA0 xP1qfC5CHHmA04NzM7AQotqXa71FWtDu9GVU5E5vHTJWjZ1q1tJT2jw6Pp4oRHU6FU6J d033T9tPfbitpoMYpF+UJP/96tsOvjj/CmaO/jzw9FVIpfT7E9YErNrb1DaClAFXxh0B b6qk2hIATpE2sG7nF813K17YMVxew+NrAxmdJMPeHDkzhzgMTauIUgV2WL27qrXLnWXr 4RldkabCEF7b4nsSIV0WfTGTDlUeQucq0inVW+VrMDSxKBArxiSkkqpVqDMNprekbIkd wU1Q== 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=wIbTKgHQucXGP2CcMT3BAsfQblK0W1kTyDVo7A8HY/8=; b=YmWk4Udwg8NWZLaqlzi1xFqAMfZ/jXo7wqKvxM0+dzGE2FdVov3ZRkvJGdEDH5ziM1 +7Wy5ni93LkUn3F5R4wVbPEIyFZ15+NfP7fcZDrxKmRNjTs/Aed8yx67KW9F5pF5csJY X0jfeKZbpBPM6MHAXBy/FEoyheoagH482Z0p542fcnZwVMyqLmx0ndKbSohWc8HxW6Nw 7nmA4vr9wyptzWJeVKKj2s09wpJE2SfjSiqXdCGedj+hDdJy0QBmBgJIa7BjxlXeeGY2 7keiz3jsAR+/zFvMdPFBl2Sj0wxM0DcSlISDwtEkK7K6OPb/RHHQEfD87yv1iisrd2xG 22gg== X-Gm-Message-State: AGRZ1gK6p1bBY7QhwqejHx/YDK8ykjq2E5rSv3SRBlds4TkgX1Vinrdh RDnuAY1/4yZCHHH2eOeB2HtJuNpw5i8rBAl9Gl5iaQ== X-Google-Smtp-Source: AJdET5f6yZD3HEydBllV+1AkjFuBb02m1JrvZeupePK1FDubQ6iuoPd82Af/N7GPegk+29yt/sobw8wFUhDU2N1uvAo= X-Received: by 2002:ad4:50c2:: with SMTP id e2mr527543qvq.201.1540343910938; Tue, 23 Oct 2018 18:18:30 -0700 (PDT) MIME-Version: 1.0 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> In-Reply-To: From: Ted Lemon Date: Tue, 23 Oct 2018 21:18:20 -0400 Message-ID: To: Martin Thomson Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4cdf10578ef4307" Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:18:35 -0000 --000000000000a4cdf10578ef4307 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable D=E2=80=99oh! :) On Tue, Oct 23, 2018 at 9:15 PM Martin Thomson wrote: > For a moment, I thought that this was SRP-related: > > https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol > > TLA-exhaustion is a think apparently. > On Wed, Oct 24, 2018 at 2:49 AM wrote: > > > > > > 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-00.txt > > Pages : 19 > > Date : 2018-10-23 > > > > 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 eliminates the dependenc= y > > on Multicast DNS as the foundation layer, 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-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 > > > > > > 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/ > > > > _______________________________________________ > > 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 > --000000000000a4cdf10578ef4307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
D=E2=80=99oh! =C2=A0:)

On Tue, Oct 23, 2018 at 9:15 PM Martin T= homson <martin.thomson@gmail= .com> wrote:
For a moment, I= thought that this was SRP-related:

https://en.wikipedia.org/wiki/Secure_Re= mote_Password_protocol

TLA-exhaustion is a think apparently.
On Wed, Oct 24, 2018 at 2:49 AM <internet-drafts@ietf.org> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Extensions for Scalable DNS Service D= iscovery WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Service Registration Protocol for DNS-Based Service Discovery >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Stuart Cheshire
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ted Lemon
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-dnssd-srp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2018-10-23
>
> Abstract:
>=C2=A0 =C2=A0 The Service Registration Protocol for DNS-Based Service D= iscovery
>=C2=A0 =C2=A0 uses the standard DNS Update mechanism to enable DNS-Base= d Service
>=C2=A0 =C2=A0 Discovery using only unicast packets.=C2=A0 This eliminat= es the dependency
>=C2=A0 =C2=A0 on Multicast DNS as the foundation layer, which greatly i= mproves
>=C2=A0 =C2=A0 scalability and improves performance on networks where mu= lticast
>=C2=A0 =C2=A0 service is not an optimal choice, particularly 802.11 (Wi= -Fi) and
>=C2=A0 =C2=A0 802.15.4 (IoT) networks.=C2=A0 DNS-SD Service registratio= n uses public
>=C2=A0 =C2=A0 keys and SIG(0) to allow services to defend their registr= ations
>=C2=A0 =C2=A0 against attack.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ie= tf-dnssd-srp/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnssd= -srp-00
> https://datatracker.ietf.org/doc/h= tml/draft-ietf-dnssd-srp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> 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
--000000000000a4cdf10578ef4307-- From nobody Wed Oct 24 11:13:26 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582E8130DF0 for ; Wed, 24 Oct 2018 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51ReIhkZnSNE for ; Wed, 24 Oct 2018 11:13:23 -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 A7B9A12777C for ; Wed, 24 Oct 2018 11:13:23 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.224.116]) (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 E0F8C22217 for ; Wed, 24 Oct 2018 14:13:22 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 14:13:22 -0400 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> To: dnssd@ietf.org In-Reply-To: <154030974108.31401.380315367024024351@ietfa.amsl.com> Message-Id: <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:13:25 -0000 If you were present in Montr=C3=A9al, you may remember that I supported = this work for adoption but wanted to see the named changed. There didn=E2=80=99t seem to be any other responses one way or the = other. Since I believe in rough consensus, it would be good to know if = others feel the same. The discussion was then moved to the list and can be found in the = archives. My main objection was that because it wasn=E2=80=99t possible to use = encryption with this scheme, it was not a general purpose solution and = had to be restricted to a subset of the use cases. Therefore, it should = have a name that reflects it=E2=80=99s inherent limitations. Thanks, Tom > On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Service Registration Protocol for DNS-Based = Service Discovery > Authors : Stuart Cheshire > Ted Lemon > Filename : draft-ietf-dnssd-srp-00.txt > Pages : 19 > Date : 2018-10-23 >=20 > 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 eliminates the = dependency > on Multicast DNS as the foundation layer, 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnssd-srp-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Oct 24 11:18:59 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02475130DF0 for ; Wed, 24 Oct 2018 11:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBiPPsJ0XBrz for ; Wed, 24 Oct 2018 11:18:57 -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 0D1FE124C04 for ; Wed, 24 Oct 2018 11:18:57 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.224.116]) (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 5C2E42221D for ; Wed, 24 Oct 2018 14:18:56 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 14:18:55 -0400 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> To: dnssd@ietf.org In-Reply-To: <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:18:58 -0000 > On Oct 24, 2018, at 2:13 PM, Tom Pusateri wrote: >=20 > If you were present in Montr=C3=A9al, you may remember that I = supported this work for adoption but wanted to see the named changed. ^named^name parapraxis (Freudian slip)? Tom= From nobody Wed Oct 24 12:56:15 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776F5124C04 for ; Wed, 24 Oct 2018 12:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 oEjK1WWwY1mU for ; Wed, 24 Oct 2018 12:56:11 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 5E9A812785F for ; Wed, 24 Oct 2018 12:56:11 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id j46-v6so7077901qtc.9 for ; Wed, 24 Oct 2018 12:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wW8KENWkfBbRnTwcKa9OEIgqEK2rJGI/MhBHFIPvjO4=; b=Dyi+QG34R/XH7AcyK5DbXDrZ5CkhTqY2aE4L5C3WxZDUNMMO7slSsO88BMe1Q3hFl1 +xhROPl9fnw5Y3IBQNSlzhREq1GamelRD9+X67xc7d8K6vfflnGQWjFiTVwf6f1ZOCf2 dVGIdja67o4rIqV1JAOiOOqLAR+Ji/XvxX8Sw4qH2CZn5+8kULGkmf/3uF8OEyVdawbM k1JQB0fDbDHy1FxPx37Wq7VrBJCNpWU7SZzrxjOFZTSqFo9gzqoT7YHlO2CsdvYGhNBG 1Qqf7/hSL/Zz0J8ToUVT4CmGfHc7aYdd+JlBZtsSuiM61EFipi3IMDmaJLa3Iaj90PVv yHUw== 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=wW8KENWkfBbRnTwcKa9OEIgqEK2rJGI/MhBHFIPvjO4=; b=cyRn2dCiN8Iv16eksvCoBsIPqL9MmrMIjRbkSsLzH6jnUcBcS3/EiRce4MCs0SoecY 2Z7n5XZjDKeWmwsbVRvAr/8Ym+EE8DnJ3MvdSEipCY7FB4AfsJtozsI5pj0je3uWfoQP kGJVpt+oW0VDt03u5pncy79j8JJs+/84rm+t7Qvbf+yHxl+m9t+p2Vh6ve45QfQq8h05 oxeh8tPR4zVV4V2S6UFa1FuW/jFBP6h1S0HYBtSSeEtXS6Odp7Wj38ZbOPTzEk9Hgp/6 jf1jEAEVh8xE/gV0iFC+TGUQxSOlUdaEzTim6FN2mJjuQmF9PFFOjRzJSSwcUQIl6Gxq qhSQ== X-Gm-Message-State: AGRZ1gIar9bFMbn/X8v1CgLmEjBJMps3cnATf9teiktqBEnBjiRy27je c+OJw91nd9MUEL6zsLi6W4ycQPMLQA9LEYzqeVNmzf5c6Kc= X-Google-Smtp-Source: AJdET5e5C5fKmg2SHsuDzHMvj4WlQQBYgS8P7jyN8u/uWnUHhLojoQlb2Ek7hYWzd56wQYoFcctxmAzvSCbUS8n1EYQ= X-Received: by 2002:ac8:24e3:: with SMTP id t32-v6mr3838318qtt.43.1540410970498; Wed, 24 Oct 2018 12:56:10 -0700 (PDT) MIME-Version: 1.0 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> In-Reply-To: <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> From: Ted Lemon Date: Wed, 24 Oct 2018 15:55:33 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000b4833c0578fee0e6" Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 19:56:15 -0000 --000000000000b4833c0578fee0e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm, my recollection is that there was a long discussion on the mailing list, and you were the odd man out. In any case, SRP can be done over DoT, so encryption is certainly possible if required. On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri wrote: > If you were present in Montr=C3=A9al, you may remember that I supported t= his > work for adoption but wanted to see the named changed. > > There didn=E2=80=99t seem to be any other responses one way or the other.= Since I > believe in rough consensus, it would be good to know if others feel the > same. > > The discussion was then moved to the list and can be found in the archive= s. > > My main objection was that because it wasn=E2=80=99t possible to use encr= yption > with this scheme, it was not a general purpose solution and had to be > restricted to a subset of the use cases. Therefore, it should have a name > that reflects it=E2=80=99s inherent limitations. > > Thanks, > Tom > > > > On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote: > > > > > > 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-00.txt > > Pages : 19 > > Date : 2018-10-23 > > > > 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 eliminates the dependency > > on Multicast DNS as the foundation layer, 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-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 > > > > > > 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/ > > > > _______________________________________________ > > 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 > --000000000000b4833c0578fee0e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm, my recollection is that there was a long discussion on= the mailing list, and you were the odd man out.=C2=A0 =C2=A0In any case, S= RP can be done over DoT, so encryption is certainly possible if required.
On Wed, Oct 24, 2018 at= 2:13 PM Tom Pusateri <pusateri@ba= ngj.com> wrote:
If you were = present in Montr=C3=A9al, you may remember that I supported this work for a= doption but wanted to see the named changed.

There didn=E2=80=99t seem to be any other responses one way or the other. S= ince I believe in rough consensus, it would be good to know if others feel = the same.

The discussion was then moved to the list and can be found in the archives.=

My main objection was that because it wasn=E2=80=99t possible to use encryp= tion with this scheme, it was not a general purpose solution and had to be = restricted to a subset of the use cases. Therefore, it should have a name t= hat reflects it=E2=80=99s inherent limitations.

Thanks,
Tom


> On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Extensions for Scalable DNS Service D= iscovery WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Service Registration Protocol for DNS-Based Service Discovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Stuart Cheshire
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Ted Lemon
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnssd-srp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-10-23
>
> Abstract:
>=C2=A0 =C2=A0The Service Registration Protocol for DNS-Based Service Di= scovery
>=C2=A0 =C2=A0uses the standard DNS Update mechanism to enable DNS-Based= Service
>=C2=A0 =C2=A0Discovery using only unicast packets.=C2=A0 This eliminate= s the dependency
>=C2=A0 =C2=A0on Multicast DNS as the foundation layer, which greatly im= proves
>=C2=A0 =C2=A0scalability and improves performance on networks where mul= ticast
>=C2=A0 =C2=A0service is not an optimal choice, particularly 802.11 (Wi-= Fi) and
>=C2=A0 =C2=A0802.15.4 (IoT) networks.=C2=A0 DNS-SD Service registration= uses public
>=C2=A0 =C2=A0keys and SIG(0) to allow services to defend their registra= tions
>=C2=A0 =C2=A0against attack.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ie= tf-dnssd-srp/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnssd= -srp-00
> https://datatracker.ietf.org/doc/h= tml/draft-ietf-dnssd-srp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> 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
--000000000000b4833c0578fee0e6-- From nobody Wed Oct 24 13:35:21 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B325130E19 for ; Wed, 24 Oct 2018 13:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md86uKBajKND for ; Wed, 24 Oct 2018 13:35:16 -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 6C97F130E18 for ; Wed, 24 Oct 2018 13:35:15 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.224.116]) (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 6D7762225D; Wed, 24 Oct 2018 16:35:14 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_58BB36BD-CEA6-4CDE-B55B-785CD9B40C4F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 16:35:12 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <154030974108.31401.380315367024024351@ietfa.amsl.com> <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 20:35:19 -0000 --Apple-Mail=_58BB36BD-CEA6-4CDE-B55B-785CD9B40C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looking at the archive, Toke was the only other person that commented = and he didn=E2=80=99t specifically comment about the name, just that he = supported adoption. So that=E2=80=99s 1-1 not counting the authors. Maybe encryption was more specific than I meant to state as a concern. = =46rom the document: "SRP updates have no authorization semantics other than first-come, first-served. This means that if an attacker from outside of the administrative domain of the server knows the server's IP address, it can in principle send updates to the server that will be processed = successfully. Servers should therefore be configured to reject updates from source addresses outside of the administrative domain of the server.=E2=80=9D The main problem is that it=E2=80=99s restricted to an administrative = domain. And previously, you stated that encryption would break the goals of the = protocol because it=E2=80=99s supposed to be done in a single message = which can=E2=80=99t happen when using DoT. Tom > On Oct 24, 2018, at 3:55 PM, Ted Lemon wrote: >=20 > Hm, my recollection is that there was a long discussion on the mailing = list, and you were the odd man out. In any case, SRP can be done over = DoT, so encryption is certainly possible if required. >=20 > On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri > wrote: > If you were present in Montr=C3=A9al, you may remember that I = supported this work for adoption but wanted to see the named changed. >=20 > There didn=E2=80=99t seem to be any other responses one way or the = other. Since I believe in rough consensus, it would be good to know if = others feel the same. >=20 > The discussion was then moved to the list and can be found in the = archives. >=20 > My main objection was that because it wasn=E2=80=99t possible to use = encryption with this scheme, it was not a general purpose solution and = had to be restricted to a subset of the use cases. Therefore, it should = have a name that reflects it=E2=80=99s inherent limitations. >=20 > Thanks, > Tom >=20 >=20 > > On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org = wrote: > >=20 > >=20 > > 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. > >=20 > > Title : Service Registration Protocol for DNS-Based = Service Discovery > > Authors : Stuart Cheshire > > Ted Lemon > > Filename : draft-ietf-dnssd-srp-00.txt > > Pages : 19 > > Date : 2018-10-23 > >=20 > > 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 eliminates the = dependency > > on Multicast DNS as the foundation layer, 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. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ = > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dnssd-srp-00 = > > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 = > >=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 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ = > >=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 = > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_58BB36BD-CEA6-4CDE-B55B-785CD9B40C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looking at the archive, Toke was the only other person that = commented and he didn=E2=80=99t specifically comment about the name, = just that he supported adoption.

So that=E2=80=99s 1-1 not counting the authors.

Maybe = encryption was more specific than I meant to state as a concern. =46rom = the document:

"SRP updates have no authorization semantics = other than first-come,
first-served.  This = means that if an attacker from outside of the
administrative domain of the server knows the server's IP = address, it
can in principle send updates to the = server that will be processed successfully.
Servers = should therefore be configured to reject updates from source
addresses outside of the administrative domain of the = server.=E2=80=9D

The main problem is that it=E2=80=99s restricted to an = administrative domain.

And previously, you stated that encryption would break the = goals of the protocol because it=E2=80=99s supposed to be done in a = single message which can=E2=80=99t happen when using DoT.

Tom

On Oct = 24, 2018, at 3:55 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, my recollection is that there was a long discussion on = the mailing list, and you were the odd man out.   In any case, = SRP can be done over DoT, so encryption is certainly possible if = required.

On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri <pusateri@bangj.com> = wrote:
If you were present in Montr=C3=A9al, you may = remember that I supported this work for adoption but wanted to see the = named changed.

There didn=E2=80=99t seem to be any other responses one way or the = other. Since I believe in rough consensus, it would be good to know if = others feel the same.

The discussion was then moved to the list and can be found in the = archives.

My main objection was that because it wasn=E2=80=99t possible to use = encryption with this scheme, it was not a general purpose solution and = had to be restricted to a subset of the use cases. Therefore, it should = have a name that reflects it=E2=80=99s inherent limitations.

Thanks,
Tom


> On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote:
>
>
> 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-00.txt
>       Pages          =  : 19
>       Date          =   : 2018-10-23
>
> 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 = eliminates the dependency
>   on Multicast DNS as the foundation layer, 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-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00
>
>
> 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/
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd

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

= --Apple-Mail=_58BB36BD-CEA6-4CDE-B55B-785CD9B40C4F-- From nobody Wed Oct 24 13:47:55 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36588130E13 for ; Wed, 24 Oct 2018 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, 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 AVskrjf02MzG for ; Wed, 24 Oct 2018 13:47:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 BDD9E128B14 for ; Wed, 24 Oct 2018 13:47:51 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9OKb7us045248 for ; Wed, 24 Oct 2018 16:47:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2naxwm2kq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Oct 2018 16:47:50 -0400 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 w9OKln2d029395 for ; Wed, 24 Oct 2018 16:47:50 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9OKllrX029355 for ; Wed, 24 Oct 2018 16:47:48 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 7C824412F809 for ; Wed, 24 Oct 2018 20:47:47 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 6A925412F808 for ; Wed, 24 Oct 2018 20:47:47 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.143]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 16:47:47 -0400 From: "STARK, BARBARA H" To: "dnssd@ietf.org" Thread-Topic: dnssd IETF 103 agenda draft Thread-Index: AdRr2WqY/o4wjW7zTOuGLiJHTm4AKw== Date: Wed, 24 Oct 2018 20:47:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DEFF1E4@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.244.206] 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=2018-10-24_07:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810240172 Archived-At: Subject: [dnssd] dnssd IETF 103 agenda draft 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, 24 Oct 2018 20:47:53 -0000 Hi dnssd, I've put together a draft agenda for the F2F in Bangkok. So you don't have = to click a link, I've copied it below. But if you love clicking links, it's= at https://datatracker.ietf.org/doc/agenda-103-dnssd/ . Please let me and = David know what adjustments you'd like.=20 I'm wondering what we should we do with Discovery Relay? Do we need time on= the agenda to discuss hopes and plans for the future? To reiterate David's= email to the group end of September: " We will not be progressing this document beyond the WG until we receive c= omments or statements of support. Please read the draft and comment on the list, even if your only comment is= that you support the document moving forward. The chairs would also like to hear more about implementation experience." Barbara ------------------------------------------------------------- DNSSD WG Agenda IETF 103, Bangkok, Thailand Thursday, November 8, 2018 13:50-15:50 local time (Thursday Afternoon session I) Meeting 2 Room Introduction -- Chairs -- 5 mins Note: draft-ietf-dnssd-hybrid is in RFC Editor's queue,=20 waiting for DNS Push Notifications (agenda item) and DNS Statefu= l Operations=20 (draft-ietf-dnsop-session-signal-18 has been submitted for public= ation) In WGLC since July, not updated, and need to do something with this: Discovery Relay ( draft-ietf-dnssd-mdns-relay) Roadmap -- Stuart Cheshire -- 5 mins draft-cheshire-dnssd-roadmap (Service Discovery Road Map) DNS Push Notifications -- Tom Pusateri or Stuart Cheshire? -- 15 minutes draft-ietf-dnssd-push (DNS Push) In WGLC Service Registration Protocol for DNS-Based Service Discovery -- Ted Lemon = -- 15 mins draft-ietf-dnssd-srp Recently adopted. DNS-SD Pairing -- Christian Huitema -- 20 minutes draft-ietf-dnssd-pairing draft-ietf-dnssd-pairing-info =09 Privacy -- Christian Huitema or Stuart Cheshire? -- 30 mins Several adopted drafts draft-ietf-dnssd-prireq draft-ietf-dnssd-privacy draft-ietf-dnssd-privacyscaling Rechartering -- Chairs & Tom Pusateri-- 15 mins Conclusion -- Chairs -- 5 mins From nobody Wed Oct 24 14:03:03 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E32130E19 for ; Wed, 24 Oct 2018 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 GFwnwlHbJTDM for ; Wed, 24 Oct 2018 14:02:57 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 76CC2128D68 for ; Wed, 24 Oct 2018 14:02:57 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id l41-v6so7326580qtl.8 for ; Wed, 24 Oct 2018 14:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aXxkg1R7OWTNBTM2ivOgFMTHxJC7i3taUca3bW4R1vU=; b=WCRUJ5/LUVX0IByw+RJhEmYVC55siBObAA7Pw+z4VZftZm+xKZRzHKH5Nh/hp2sqFV IZpi13dM9zqpwFF/2jCJa7FB3AS/WwNF0KGgS0/GiO2vnw7xp9eAmPWVXVmBue5fVl5+ aAb+/RbEiGUzkX2YLhxPdskI99K4OCqZHjZyEGR2hTHXx+rvS63d6TZ+a5GnraMFm9B6 MP2MmPeSd+TaxEsZdXG4SgeesiGUAlxQEBqkUtV84sDpt660aYRSn+7rLGaQPeR4v5SS Qwj+GT0qYc3xmcKTEpQzQFeFaM5P3GZDcRqFn32PBeqXAxIQBIcFjejYpfWG/9l9884W nQZg== 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=aXxkg1R7OWTNBTM2ivOgFMTHxJC7i3taUca3bW4R1vU=; b=i8SinJMFnCX0fdzfFmrTumgHjuwy96Jii/I95z5cNaygTs/SBsJMUpvIh4mg8dtl2m y1ex372XwntanvPerQxRA/a8jCTgRChAf+djiu9hBAEZqtR3d/nAp5SfkNRxWaHN7SJ6 mynYU9k0WTQ0VacyKyfCgn/80T646/mHvZqG4NlOa/m8/QC/fRFvTHcUh+05Wen5GBxs IZwokMs5B3NlzQIB3Ksvb5Op1PCVF5XJt5ALn6zWqwQzAPUABX6z4jjoM3Qf0mHClpfx AW5/d0uBfQCK5f2hP8wDDHESDkzmaFq2e0pvnuKJreX0XjmlGeqzfBBn3smOuuPFDMxD A4wQ== X-Gm-Message-State: AGRZ1gIEgdq8KIhc/0Qi2xtb4W1pCazVxYrmpX6f36M/Ol4oKrq63EgO T8crwLnNTfFBQSi0aJXLW6wPO4BPZpMtkfteIhHNm2+IjEM= X-Google-Smtp-Source: AJdET5cwPoZbfhr4oyZsmOH6FDTaJPhuHsk2PnaQW+p2ChXXvulG6zOJ+X04hO6oWvMUtgzZ+AqkhbDMXzGqKjTJHGw= X-Received: by 2002:aed:366a:: with SMTP id e97-v6mr4151772qtb.75.1540414976481; Wed, 24 Oct 2018 14:02:56 -0700 (PDT) MIME-Version: 1.0 References: <154030974108.31401.380315367024024351@ietfa.amsl.com> <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> In-Reply-To: From: Ted Lemon Date: Wed, 24 Oct 2018 17:02:19 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000007af9170578ffcf6d" Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 21:03:02 -0000 --0000000000007af9170578ffcf6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right, I remember the discussion now. But service registration is always limited to the administrative domain. Your objection doesn't really make any sense. This is not DNS update. This is DNSSD Service Registration. It's only for service registration, and services are registered where they are present, not across the Internet from somewhere else. If you think there's a SRP that works from random locations in the Internet, you should write up the use case and we can talk about it. But I think it would be the protocol that would require the special name, not this one. Also, I think Stuart and I both count as 1, so it's 2:1. :) On Wed, Oct 24, 2018 at 4:35 PM Tom Pusateri wrote: > Looking at the archive, Toke was the only other person that commented and > he didn=E2=80=99t specifically comment about the name, just that he suppo= rted > adoption. > > So that=E2=80=99s 1-1 not counting the authors. > > Maybe encryption was more specific than I meant to state as a concern. > From the document: > > "SRP updates have no authorization semantics other than first-come, > first-served. This means that if an attacker from outside of the > administrative domain of the server knows the server's IP address, it > can in principle send updates to the server that will be processed > successfully. > Servers should therefore be configured to reject updates from source > addresses outside of the administrative domain of the server.=E2=80=9D > > The main problem is that it=E2=80=99s restricted to an administrative dom= ain. > > And previously, you stated that encryption would break the goals of the > protocol because it=E2=80=99s supposed to be done in a single message whi= ch can=E2=80=99t > happen when using DoT. > > Tom > > On Oct 24, 2018, at 3:55 PM, Ted Lemon wrote: > > Hm, my recollection is that there was a long discussion on the mailing > list, and you were the odd man out. In any case, SRP can be done over > DoT, so encryption is certainly possible if required. > > On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri wrote: > >> If you were present in Montr=C3=A9al, you may remember that I supported = this >> work for adoption but wanted to see the named changed. >> >> There didn=E2=80=99t seem to be any other responses one way or the other= . Since I >> believe in rough consensus, it would be good to know if others feel the >> same. >> >> The discussion was then moved to the list and can be found in the >> archives. >> >> My main objection was that because it wasn=E2=80=99t possible to use enc= ryption >> with this scheme, it was not a general purpose solution and had to be >> restricted to a subset of the use cases. Therefore, it should have a nam= e >> that reflects it=E2=80=99s inherent limitations. >> >> Thanks, >> Tom >> >> >> > On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote: >> > >> > >> > 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-00.txt >> > Pages : 19 >> > Date : 2018-10-23 >> > >> > 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 eliminates the dependenc= y >> > on Multicast DNS as the foundation layer, 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-00 >> > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 >> > >> > >> > 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/ >> > >> > _______________________________________________ >> > dnssd mailing list >> > dnssd@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnssd >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --0000000000007af9170578ffcf6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, I remember the discussion now.=C2=A0 =C2=A0But serv= ice registration is always limited to the administrative domain.=C2=A0 =C2= =A0Your objection doesn't really make any sense.=C2=A0 =C2=A0This is no= t DNS update.=C2=A0 =C2=A0This is DNSSD Service Registration.=C2=A0 =C2=A0I= t's only for service registration, and services are registered where th= ey are present, not across the Internet from somewhere else.=C2=A0 =C2=A0If= you think there's a SRP that works from random locations in the Intern= et, you should write up the use case and we can talk about it.=C2=A0 =C2=A0= But I think it would be the protocol that would require the special name, n= ot this one.

Also, I think Stuart and I both count as 1,= so it's 2:1.=C2=A0 =C2=A0:)

=
On Wed, Oct 24, 2018 at 4:35 PM Tom Pusateri <pusateri@bangj.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Looking at the archive, Toke was the only other person = that commented and he didn=E2=80=99t specifically comment about the name, j= ust that he supported adoption.

So that=E2=80=99s 1-1 no= t counting the authors.

Maybe encryption was more sp= ecific than I meant to state as a concern. From the document:
"SRP updates have no authorization semantics other th= an first-come,
first-served.=C2=A0 This means that if an attacker= from outside of the
administrative domain of the server knows th= e server's IP address, it
can in principle send updates to th= e server that will be processed successfully.
Servers should ther= efore be configured to reject updates from source
addresses outsi= de of the administrative domain of the server.=E2=80=9D

The main problem is that it=E2=80=99s restricted to an administrative= domain.

And previously, you stated that encryptio= n would break the goals of the protocol because it=E2=80=99s supposed to be= done in a single message which can=E2=80=99t happen when using DoT.
<= div>

Tom

On= Oct 24, 2018, at 3:55 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, my re= collection is that there was a long discussion on the mailing list, and you= were the odd man out.=C2=A0 =C2=A0In any case, SRP can be done over DoT, s= o encryption is certainly possible if required.

On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri <= pusateri@bangj.com<= /a>> wrote:
If you were present = in Montr=C3=A9al, you may remember that I supported this work for adoption = but wanted to see the named changed.

There didn=E2=80=99t seem to be any other responses one way or the other. S= ince I believe in rough consensus, it would be good to know if others feel = the same.

The discussion was then moved to the list and can be found in the archives.=

My main objection was that because it wasn=E2=80=99t possible to use encryp= tion with this scheme, it was not a general purpose solution and had to be = restricted to a subset of the use cases. Therefore, it should have a name t= hat reflects it=E2=80=99s inherent limitations.

Thanks,
Tom


> On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Extensions for Scalable DNS Service D= iscovery WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Service Registration Protocol for DNS-Based Service Discovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Stuart Cheshire
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Ted Lemon
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnssd-srp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-10-23
>
> Abstract:
>=C2=A0 =C2=A0The Service Registration Protocol for DNS-Based Service Di= scovery
>=C2=A0 =C2=A0uses the standard DNS Update mechanism to enable DNS-Based= Service
>=C2=A0 =C2=A0Discovery using only unicast packets.=C2=A0 This eliminate= s the dependency
>=C2=A0 =C2=A0on Multicast DNS as the foundation layer, which greatly im= proves
>=C2=A0 =C2=A0scalability and improves performance on networks where mul= ticast
>=C2=A0 =C2=A0service is not an optimal choice, particularly 802.11 (Wi-= Fi) and
>=C2=A0 =C2=A0802.15.4 (IoT) networks.=C2=A0 DNS-SD Service registration= uses public
>=C2=A0 =C2=A0keys and SIG(0) to allow services to defend their registra= tions
>=C2=A0 =C2=A0against attack.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ie= tf-dnssd-srp/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnssd= -srp-00
> https://datatracker.ietf.org/doc/h= tml/draft-ietf-dnssd-srp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd
--0000000000007af9170578ffcf6d-- From bradley@apple.com Thu Oct 25 12:11:10 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EED6130E3A for ; Thu, 25 Oct 2018 12:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 X_EJj1tKfRVg for ; Thu, 25 Oct 2018 12:11:08 -0700 (PDT) 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 40206126DBF for ; Thu, 25 Oct 2018 12:11:08 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9PJ7HUd038573 for ; Thu, 25 Oct 2018 12:11:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : message-id : references : to : date; s=20180706; bh=G/tbfIDXnqrDcu6a9t7AP6uGT/1nfn2IIm33TJFNRzA=; b=o/0h1z0Q43LV7BLXhgvmTVzKxAPaMvDWEC2sjK9w5pD5viNZjDCFMyh4p511XlvOI31B rbGDTnftNc/Zc98Jr7OhFp2IPDMIEN+1tkV8pyuCcFeeTreUCrXcwZk79KJPDAEeFN4h NvhhUS14Vn0LL+S7Z8AZQNBxHvRxD5AoSLITl3zQMAcd8tGe4v6Tuf9FZVAjNXwLm3gz HPEVLTraTiaZULlrpWR/zBQ8u+sqNCRD9YnjLO0dE2OF+rEu8BpJYZOqyEKotUJBfFX2 NC39UNi49ZTbAR3lv/p8Eb0+fyRLfrVuro/aHxIXYUGE3pzC36XB/zql0Vf9l16N1fvA DQ== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2n8120ps2q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 25 Oct 2018 12:11:07 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7diHb7fenQtxdiMUXUyioQ)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PH6002TE5AIYSC0@mr2-mtap-s02.rno.apple.com> for dnssd@ietf.org; Thu, 25 Oct 2018 12:11:06 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH600G004SMUB00@nwk-mmpp-sz10.apple.com> for dnssd@ietf.org; Thu, 25 Oct 2018 12:11:06 -0700 (PDT) X-Va-A: X-Va-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-Va-E-CD: 1145faa4443465047ea0b3fb1f4a1092 X-Va-R-CD: bdf50e76f823da9a31af636b5a07cae4 X-Va-CD: 0 X-Va-ID: f1ec4853-3602-405f-960c-ed5333b051d5 X-V-A: X-V-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-V-E-CD: 1145faa4443465047ea0b3fb1f4a1092 X-V-R-CD: bdf50e76f823da9a31af636b5a07cae4 X-V-CD: 0 X-V-ID: 05e7b8dc-2601-48a9-81fe-22fac6cd3120 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH600M0058GT100@nwk-mmpp-sz10.apple.com> for dnssd@ietf.org; Thu, 25 Oct 2018 12:11:05 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-25_10:,, signatures=0 Received: from [17.234.24.52] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PH6008OS5AGF5A0@nwk-mmpp-sz10.apple.com> for dnssd@ietf.org; Thu, 25 Oct 2018 12:11:04 -0700 (PDT) Sender: bradley@apple.com From: Bob Bradley Message-id: <29C7145A-5AB4-4686-8FA7-015F50DE4529@apple.com> References: <154031233297.31357.18023345126032301204.idtracker@ietfa.amsl.com> To: dnssd@ietf.org Date: Thu, 25 Oct 2018 12:11:04 -0700 X-Mailer: Apple Mail (2.3445.102.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-25_09:, , signatures=0 Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-bradley-dnssd-private-discovery-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: Thu, 25 Oct 2018 19:12:57 -0000 --Boundary_(ID_7diHb7fenQtxdiMUXUyioQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Here's a new draft describing an addition to DNS-SD to help preserve privacy. The basic idea is to use a 2-phase approach. First, it probes the network to find peers it has cryptographic relationships with (i.e. "friends"). Second, it does encrypted and authenticated service discovery with each friend. There were a few goals: 1. Advertise and discover in a way that makes identifying and tracking users more difficult. 2. Provide per-user confidentiality so it's difficult for even your friends to determine the services you are offering or discovering. 3. Reduce discovery-related traffic on networks with a lot of non-friends. And some non-goals: 1. Solving the privacy leaking issues at layers below DNS-SD, such as relatively static IP addresses and MAC addresses being used to correlate service discovery. Those issues are important, but require a larger effort across several working groups so this focuses on DNS-SD first. 2. Solving the problem of establishing cryptographic relationships between peers. There are also several things that need more thought, such as working with sleep proxies and traffic analysis mitigation. The plan is for Chris Wood to present this at IETF 103. > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-bradley-dnssd-private-discovery-00.txt > Date: October 23, 2018 at 9:32:12 AM PDT > To: Bob Bradley > > > A new version of I-D, draft-bradley-dnssd-private-discovery-00.txt > has been successfully submitted by Bob Bradley and posted to the > IETF repository. > > Name: draft-bradley-dnssd-private-discovery > Revision: 00 > Title: Private Discovery > Document date: 2018-10-22 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-bradley-dnssd-private-discovery-00.txt > Status: https://datatracker.ietf.org/doc/draft-bradley-dnssd-private-discovery/ > Htmlized: https://tools.ietf.org/html/draft-bradley-dnssd-private-discovery-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bradley-dnssd-private-discovery > > > Abstract: > This document specifies a mechanism for advertising and discovering > in a private 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 > --Boundary_(ID_7diHb7fenQtxdiMUXUyioQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Here's a new draft describing an addition = to DNS-SD to help preserve privacy. The basic idea is to use a 2-phase = approach. First, it probes the network to find peers it has = cryptographic relationships with (i.e. "friends"). Second, it does = encrypted and authenticated service discovery with each = friend.

There= were a few goals:

1. Advertise and discover in a way that makes identifying and = tracking users more difficult.
2. Provide per-user confidentiality so it's difficult for = even your friends to determine the services you are offering or = discovering.
3. = Reduce discovery-related traffic on networks with a lot of = non-friends.

And = some non-goals:

1. = Solving the privacy leaking issues at layers below DNS-SD, such as = relatively static IP addresses and MAC addresses being used to correlate = service discovery. Those issues are important, but require a larger = effort across several working groups so this focuses on DNS-SD = first.
2. = Solving the problem of establishing cryptographic relationships between = peers.

There= are also several things that need more thought, such as working with = sleep proxies and traffic analysis mitigation.

The plan is for Chris Wood to present = this at IETF 103.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-bradley-dnssd-private-discovery-00.txt
Date: = October 23, 2018 at 9:32:12 AM = PDT
To: = Bob Bradley <bradley@apple.com>

A new version of I-D, = draft-bradley-dnssd-private-discovery-00.txt
has been = successfully submitted by Bob Bradley and posted to the
IETF= repository.

Name: = draft-bradley-dnssd-private-discovery
Revision: 00
Title:= = Private Discovery
Document date: = 2018-10-22
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-bradley-dnssd-privat= e-discovery-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-bradley-dnssd-private-di= scovery/
Htmlized: =       https://tools.ietf.org/html/draft-bradley-dnssd-private-discove= ry-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bradley-dnssd-priva= te-discovery


Abstract:
  This document specifies a mechanism for = advertising and discovering
  in a private = 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


= --Boundary_(ID_7diHb7fenQtxdiMUXUyioQ)-- From nobody Fri Oct 26 00:08:53 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55CA127AC2 for ; Fri, 26 Oct 2018 00:08:51 -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 uVOdugiE5Kvc for ; Fri, 26 Oct 2018 00:08:49 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D902128CFD for ; Fri, 26 Oct 2018 00:08:49 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gFwEe-0003hJ-KS for dnssd@ietf.org; Fri, 26 Oct 2018 09:08:46 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gFwEV-0007Ga-8X for dnssd@ietf.org; Fri, 26 Oct 2018 03:08:39 -0400 Received: (qmail 4979 invoked from network); 26 Oct 2018 07:08:32 -0000 Received: from unknown (HELO [172.16.33.227]) (Authenticated-user:_huitema@huitema.net@[217.16.13.130]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Oct 2018 07:08:31 -0000 To: dnssd From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb 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: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> Date: Fri, 26 Oct 2018 09:08:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.47) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5m4DAVcvzNRyfnASbsuZto1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax0H2emL9OFLzzzHmk+tWpaVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5XXP/PhacSgLwLXdxYAFaWE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezqWtkpJGM3LlmFs5AdkE6VbBF60t09JPqYDV9lpEWTlrrS9EUFbOHH te+8JJ1uQ3Vk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUoiPn/2xNqt6sQVacVXeY6AU 1zqm/evfkH8cHl25+qKdzoZJbv2GES9fRTEUwtaGCR2vWOKTBJk2Pbgs7SLYxsB09WmAGZznescg 91X6BuEZeHkJ3RppXwEO+1/ngUOKuHG5BnVj6tDKYf18xfK0O5ipahgr6AgAfpld1xYSvcj+w6nI oDr0sXUZ7YZoZ/GZ+rQ53ngkwHVnz6S3TKYH8fH6vvsamCqhsCKWQTQWW5aiOYN2LGYOY+RZZ70I EJvMPP9qwM7RXpJS8RjTdyh2j5BSM6Vge5/tyLofFHTUZzjpzRBCCyVCnQKBwcrUTMoPTDRj9D8H LKHAKpPGP8EPnuBvlPE9yn4+7R7hw716lUpV X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: [dnssd] Next steps for privacy discovery 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, 26 Oct 2018 07:08:52 -0000 With some prodding from David and Barbara, I resubmitted the DNSSD Privacy and Pairing drafts before the Bangkok meeting. The changes are: * For both drafts, add reference to the privacy requirement draft and to the scaling draft, * For both drafts, add a short paragraph in the intro stating that things might change based on the scaling analysis, * For the privacy draft, remove the requirement analysis part and replace it by a reference to the requirement draft. David is prodding me to write a complete revision of the privacy draft, using the "shared public key" approach, which has very good scaling capabilities and reasonably robust resilience to attacks. It is a bit different from the draft that Bob Bradley sent, and I will comment on tha= t later. I could not submitted a revised discovery proposal before the dead= line, but here are the broad lines of what I would do:=20 1) Server has a public key, which is "somewhat secret" -- it is only provided to authorized clients and they are expected to keep it secret. 2) Single announcement per server of the form nonce|proof, where the nonce is a "predictable nonce" computed as a hash of quantized time and secret public key. 3) Clients do a search for the nonce, just like in the current spec, but there is only one nonce per server, so the client will get exactly one response. 4) If we kept the current "two phase" structure, use a TLS protocol extension to demonstrate knowledge of the server's public key in the client hello. I think we can build on the work done for SNI encryption, which would fit quite well. 5) We may consider having a different nonce for each available service, e.g. have the announcement computed as hash of quantized time, service type and secret public key. This would allow for a single phase solution.= 6) We may also have the service name used as a proof, e.g. encoding of nonce and service name with the server's private key. 7) We need to say something about protecting the service connections from clients to server. DNSSD privacy would not be that much useful if the clear text data on the service connection revealed the identity of client or server. I think a combination of SNI encryption and TLS 1.3 would work, but that may be extra work. 8) We also need to recommend randomized host names for the A/AAAA records of the servers, otherwise there is also a big leak. Some of the complexity in the DNSSD approach comes from a desire to fit into the existing DNSSD formats. This leads to some tricks like Base64 encoding of nonce, time stamps and proofs so they fit in existing fields like service type or instance name. Bob's draft jettisons DNSSD compatibility and defines a new binary format. That is definitely cleaner, but there is a trade-off: a new protocol implies that we cannot reuse the DNSSD server infrastructure. It would be interesting to gauge the WG consensus on that tradeoff. The other big difference between Bob's draft and the evolving proposal is the use of trial decryption. In Bob's approach, clients send probes that the server tries to decrypt by using the public keys of various registered peers or friends. This has scaling issues similar to the pairwise keys that we relied on in our first drafts. After discussions, we grew very concerned with these scaling issues and the corresponding potential for DOS attacks. We instead evolved towards a system of "predictable nonces". The predictable nonces are a tradeoff between privacy and performance. Predictable nonces can be precomputed by the server, which reduces the processing cost and also limits the potential of DOS attacks. But then, all authorized clients of a server can generate the same predictable nonces, and thus all authorized clients can detect the presence of other authorized clients. This reduces privacy somewhat, although not necessarily by a whole lot. All authorized clients can discover the serve= r, and thus retrieve its IP address. Network level analysis can then reveal which clients are also connecting to that server. This means that the inf= ormation potentially leaked by the predictable nonce is also available at a lower layer. I think that the trade-off is thus between a minor privacy leak an= d a significant performance gain, but of course other WG members may have a= different analysis. It would be interesting to gauge WG consensus on that= subject. Looking forward to the debates in Bangkok! -- Christian Huitema =C2=A0 -- Christian Huitema From nobody Fri Oct 26 09:57:27 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A845130DE9 for ; Fri, 26 Oct 2018 09:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 B25RQBGLhkm1 for ; Fri, 26 Oct 2018 09:57:23 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.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 73B8C127133 for ; Fri, 26 Oct 2018 09:57:23 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9QGv1Vq022392; Fri, 26 Oct 2018 09:57:14 -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=INW0mHNFDS3ULBa7f8PwKBr+e4kiG839JuNLjoImxKw=; b=rvT+sxgPscmBi+cO6M5RuECWBUp3+XGXwLz2QZhN9o0EIjiYmzOkkbh6oOWmjd+Rmg3i Rqg+9/TLBZVZ4ecxXnE+pH4HRivLvB+jVotEpH53kVdXYQWGgbLwFfVE91pU9JnazJeo l2wOKyu4clIMY3vg4G47qhXgJydpK/PlG3Fk94U9mGU3L10EUAwhMS0raCK6sqiBoR5h JetFmRfkYQ/GtvlRIqmCqLNeLji8v8r6xeZn13mbmShOkWjDzo33Cdx0XHmI5Xcm7JJ0 jkLouQwea5O1ftD+e5uCD+qg1eyscR0WFFqMJrCEwveftuzp6M1KnDxbcxw8c8NinsaB 4Q== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2n80wbtdax-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 Oct 2018 09:57:14 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PH70004FTR4TRH0@ma1-mtap-s01.corp.apple.com>; Fri, 26 Oct 2018 09:57:05 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH700D00TKJDO00@nwk-mmpp-sz13.apple.com>; Fri, 26 Oct 2018 09:57:04 -0700 (PDT) X-Va-A: X-Va-T-CD: 71dc84467274b5628813a22f30ceafa8 X-Va-E-CD: cd92e8e7a72a12fe881f4b967bb78df8 X-Va-R-CD: 23cb4d007a8cf68f9daff7890c8be7a6 X-Va-CD: 0 X-Va-ID: 8dc06b22-422e-46d9-9f7c-f7450fd3bd55 X-V-A: X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-V-E-CD: cd92e8e7a72a12fe881f4b967bb78df8 X-V-R-CD: 23cb4d007a8cf68f9daff7890c8be7a6 X-V-CD: 0 X-V-ID: 2809efbd-e003-4757-9876-5a9ca93bc4de Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH700F00TPHJ000@nwk-mmpp-sz13.apple.com>; Fri, 26 Oct 2018 09:57:04 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-26_09:,, signatures=0 Received: from [17.234.69.77] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PH7003OTTR4MO30@nwk-mmpp-sz13.apple.com>; Fri, 26 Oct 2018 09:57:04 -0700 (PDT) Sender: bradley@apple.com From: Bob Bradley In-reply-to: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> Date: Fri, 26 Oct 2018 09:57:03 -0700 Cc: dnssd Message-id: <28F9784B-6243-453E-8926-A4EA039217C9@apple.com> References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.102.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-26_09:, , signatures=0 Archived-At: Subject: Re: [dnssd] Next steps for privacy discovery 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, 26 Oct 2018 16:57:26 -0000 If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 would change it from each server advertising a _pds._tcp service instance for each of its paired peers to advertising a single _pds._tcp service instance for only itself (which sounds like a nice improvement). For that case, I think the scalability comparison between predictable nonces vs trial decryptions would be the cost of filtering additional multicast traffic vs performing additional signature verifications. Assuming a network with 50 peers and 3 of them I'm paired to, here's my understanding of the work between the two approaches: Predictable nonces: When I join the network and start discovery, I announce my own _pds._tcp service instance (hash of time). Each peer would receive it and for each of its paired peers, calculate PrivateInstanceName = 
      For RCODE =3D 2 (SERVFAIL) the delay should be chosen according to
      the level of server overload and the anticipated duration of that
      overload.  By default, a value of one minute is RECOMMENDED.  If a
      more serious server failure occurs, the delay may be longer in
      accordance with the specific problem encountered.

<=
/div>
In this case ideally there is more than one= server, and the client can try the next one in the list, rather than repea= tedly connecting to the same overloaded server.=C2=A0 =C2=A0Or are we assum= ing the client will look the server up again, and that round-robining will = take care of this?

Also in 6.2.2:

   =
   This is a misconfiguration, since this server is listed in a
      "_dns-push-tls._tcp.<zone>" SRV record, but the serve=
r itself is
      not currently configured to support DNS Push Notifications for
      that zone.  Since it is possible that the misconfiguration may be
      repaired at any time, the retry delay should not be set too high.
      By default, a value of 5 minutes is RECOMMENDED.

Probably ought to s= ay this:

      If the server being queried is not the local =
resolver, rhis is a

At the end of 6.3.1:

   The TTL of an=
 added record is stored by the client and decremented as
   time passes, with the caveat that for as long as a relevant
   subscription is active, the TTL does not decrement below 1 second.
   For as long as a relevant subscription remains active, the client
   SHOULD assume that when a record goes away the server will notify it
   of that fact.  Consequently, a client does not have to poll to verify
   that the record is still there.  Once a subscription is cancelled
   (individually, or as a result of the DSO session being closed) record
   aging resumes and records are removed from the local cache when their=C2=
=A0
=C2=A0 = =C2=A0TTL reaches zero.

There's a slight problem with this: if the caching r= esolver is doing these queries on behalf of a client, then it shouldn't= be decrementing the TTL.=C2=A0 =C2=A0Also, if we haven't received an u= pdate from the server saying that the TTL has a new value, then the TTL doe= sn't have a new value=E2=80=94it's still whatever the server sent l= ast time.=C2=A0 =C2=A0So it would actually be correct to never decrement th= e TTL while a subscription is active.=C2=A0 =C2=A0So I would suggest:

   The TTL =
of an added record is stored by the client.   While the subscription
<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)"> is active, the TTL is= not decremented, because a change to the TTL would
   produce a new update.
   For as long as a relevant subs=
cription remains active, the client
   SHOULD assume that when a record goes away the server will notify it
   of that fact.  Consequently, a client does not have to poll to verify
   that the record is still there.  Once a subscription is cancelled
   (individually, or as a result of the DSO session being closed) record
   aging for records covered by the subscription resumes and records are
   removed from the =
local cache when their=C2=A0
   TTL reaches zero.

Section 7.4 talks about TLS session resumption an= d that subscriptions have to be reinstantiated, but implies without stating= explicitly that closing a TLS session closes the DSO session.=C2=A0 =C2=A0= It might be worth saying that explicitly.=C2=A0 =C2=A0Something like:
=C2=A0 =C2=A0TLS = Session Resumption is permissible on DNS Push Notification
   servers.  The server =
may keep TLS state with Session IDs [RFC5246] or
   operate in stateless mode by sending a Session Ticket [RFC=
5077] to
   the client for it to store.  However, closing the TLS connection
   terminates the  the DSO session.  When the TLS s=
ession is
   resumed, the DNS Push Notification server will not have any
   subscription state and will proceed as with any other new DSO
   session.  Use of TLS Session Resumption allows a new TLS connection
   to be set up more quickly, but the client will still have to recreate
   any desired subscriptions.
=
In section 8, you probably ough= t to use two tables rather than one.=C2=A0 =C2=A0Also, I don't think yo= u've given enough information for the service name registration.
<= div style=3D"color:rgb(34,34,34);font-size:small;white-space:normal;font-fa= mily:Arial,Helvetica,sans-serif">
, Stuart Cheshire , Tim Wicinski , dnssd , David Schinazi Content-Transfer-Encoding: quoted-printable Message-Id: <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 27 Oct 2018 01:15:53 -0000 Thanks for the feedback! Comments inline. > On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: >=20 > I'm in favor of advancing the document. I have a few editorial = comments: >=20 > On Page 6: >=20 > For example, if a user presses the "Print" > button on their smartphone, and then leaves the phone showing the > printer discovery screen until the phone goes to sleep, then the > printer discovery screen should be automatically dismissed as the > device goes to sleep. If the user does still intend to print, this > will require them to press the "Print" button again when they wake > their phone up. >=20 >=20 > I don't think this is the right advice to give=E2=80=94it's not = necessary to dismiss the UI. It always surprises me when a context = switch results in something in the UI changing without me changing it. = The less surprising behavior would be to simply stop doing these = queries while the dialog isn't showing. The dialog isn't showing when = the phone is asleep. So maybe this text would accomplish the same = purpose without recommending a particular UI flow? >=20 > For example, if a user presses the "Print" button on their smartphone, = and then leaves the phone showing the printer discovery screen until the = phone goes to sleep, or switches > to a different app, then the push subscription should (SHOULD?) be = discontinued. When the phone wakes up, > or the user switches back to the application that is showing the print > dialog, the subscription could be reinstated, perhaps after a brief = wait > to allow the user to dismiss the dialog if they no longer intend to = print. I agree that too much implementation info here is not needed. How about: (a) A subscription should only be active when there is a valid reason to = need live data (for example, an on-screen display is currently showing = the results to the user) and the subscription SHOULD be cancelled as = soon as the need for that data ends (for example, when the user = dismisses that display). Implementations may want to implement idle = timeouts, so that if the user ceases interacting with the device, the = subscription is cancelled. > Section 3 says: >=20 > Standard DNS Queries MAY be sent over a DNS Push Notification = connection, provided that these are queries for names falling within the = server's zone (the in the "_dns-push-tls._tcp." SRV = record). The RD (Recursion Desired) bit MUST be zero. If a query is = received with the RD bit set, matching records for names falling within = the server's zones should be returned with the RA (Recursion Available) = bit clear. If the query is for a name not in the server's zone, an error = with RCODE NOTAUTH (Not Authoritative) should be=20 > returned. >=20 > Why is this? What if this is a hybrid authoritative/caching = resolver? Also, later on we do actually specify that this can work = with the local resolver. ISTM you could say this instead and capture = what is necessary: >=20 > Standard DNS Queries MAY be sent over a DNS Push Notification > connection. For any zone for which the server is authoritative, = it >=20 > MUST respond authoritatively for queries on names falling within > that zone (e.g., the in the "_dns-push-tls._tcp." SRV > record) both for DNS Push Notification queries and for normal DNS >=20 > queries. For names for which the server is acting as a caching > resolver, e.g. when the server is the local resolver, for any query > for which it supports DNS Push Notifications, it MUST also support > standard queries. That sounds better. I think the idea of subscriptions to a local = resolver came along later and this part didn=E2=80=99t get updated. >=20 > Section 4 says: >=20 > In keeping with the more recent precedent, DNS Push Notification is > defined only for TCP. DNS Push Notification clients MUST use DNS > Stateful Operations (DSO) [ > DSO] running over TLS over TCP [RFC7858]. >=20 > But section 7 says: >=20 > The Strict Privacy Usage Profile for DNS over TLS is strongly > recommended for DNS Push Notifications as defined in "Usage = Profiles > for DNS over TLS and DNS over DTLS" [ > RFC8310]. >=20 > Which is it? :) Ok, I intended to go strict only since it was a new protocol. Here is = the new text in Section 7: The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS = Push Notifications as defined in "Usage Profiles for DNS over TLS and = DNS over DTLS". Cleartext connections for DNS Push Notifications are not = permissible. Since this is a new protocol, transistion mechanisms using = the Opportunistic Privacy profile are deemed unnecessary. >=20 > Section 5 says: >=20 > Token bucket rate limiting schemes are also effective > in providing fairness by a server across numerous client requests. >=20 >=20 > [Citation Needed] >=20 > Is there any reason to say this? No. Probably better to remove it. >=20 > DNS Push Notification clients and servers MUST support DSO, but (as > stated in the DSO specification [ > DSO > ]) the server SHOULD NOT issue > any DSO messages until after the client has first initiated an > acknowledged DSO message of its own. A single server can support = DNS > Queries, DNS Updates, and DNS Push Notifications (using DSO) on the > same TCP port, and until the client has sent at least one DSO > message, the server does not know what kind of client has connected > to it. Once the client has indicated willingness to use DSO by > sending one of its own, either side of the session may then = initiate > further DSO messages at any time. >=20 >=20 > It's just reiterating what the DNS Stateful Operations document says, = and what was said previously about updates and so on. Less text = better? I agree. Ok, that=E2=80=99s as far as I got tonight. More tomorrow. Thanks! Tom From nobody Fri Oct 26 18:45:36 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DAA130DC1 for ; Fri, 26 Oct 2018 18:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.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 WMmW56NGO9ZF for ; Fri, 26 Oct 2018 18:45:32 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 00B0B1294D0 for ; Fri, 26 Oct 2018 18:45:31 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id u34-v6so3403344qth.3 for ; Fri, 26 Oct 2018 18:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FiRU1oik3+MNQhlBG87GPxrIwurQc518LrLxSGN4H30=; b=eIu72dyeopQ6mhBXGOJxVLlgIyXlGlKNZJCuZBitOwpLGm/WhfHQVD5vAXST4GLjfe DVyKq0HfFvdOs2HB0e1Fjy9GHV2jjXipTeUUmnzB6NnYS4e6xCb6trJBk8aSiz9ilziT vGDx6B5CF4lI/EETmDyhAwn0+7vgdS3aALH/jDnypM1v5TytAhTR1LRUQgmUda6zlSwu 0Q+PlyDXGTLpBmKgBHV9CrhD8K/xCw0CK+TMdkBWxxx67sJk3FyhX4n/macP70SBfK0u 5QpuDDDLBhB8CxCYenKn5Ci6GHAMFTYbpj4SvMRU7HJMeHh3dyW6Up7n5TS5vSZR50+L f7Gg== 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=FiRU1oik3+MNQhlBG87GPxrIwurQc518LrLxSGN4H30=; b=R4h09Og+E+IHSKy9MpXr1gU5wgcIwxDbHS8WGr3N6NWRa35M1HYvxDDKNHjDwY34QV lD5w1sI5FRV280ztgoQjaPUw83T7ZJRoL1n1PEMvgMvt39yNZ7ur8e80+JpaNwLx4pc+ 1XY36F/yB8w+0Gn8UCF0YV65bAnQ1T5zGzGRHNTAh/VNLBtPTktqIKDFmUXmEjX/PCe+ qLnd1OqinpkdlYZMBbeUYyb3LGyefeGYVZ8tbbCWS6/f9ErSqZ/z6fpHZc5KfP8vxj5V +RjsQ+50K7B1zeWY49QG+Aa4tQ6Xilc6bWUA38QdCOWJW8g4vzah7Ox5sBx6xCqeQ5Ik VliQ== X-Gm-Message-State: AGRZ1gIuzID4/GpWVVZbh/mo+kNKfGxIxruiGdUwoXa+3F4xWqqWOX+n xicpAgQ/1MZQMSBnpRr9G6GpBd0PmNXoV77obloC1g== X-Google-Smtp-Source: AJdET5c8B3dbcWsL6IwyX6froqHu0rArObYXX/H1ZKyocTVZUBrT6+CFKC+VJtO2vKs8mvt2bSKxHHWOLTFDK3HkrIM= X-Received: by 2002:aed:366a:: with SMTP id e97-v6mr5460898qtb.75.1540604730969; Fri, 26 Oct 2018 18:45:30 -0700 (PDT) MIME-Version: 1.0 References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> In-Reply-To: <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> From: Ted Lemon Date: Fri, 26 Oct 2018 21:45:19 -0400 Message-ID: To: Tom Pusateri Cc: David Schinazi , "Jan Komissar (jkomissa)" , Stuart Cheshire , Tim Wicinski , dnssd Content-Type: multipart/alternative; boundary="000000000000baacb805792bfd31" Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 27 Oct 2018 01:45:35 -0000 --000000000000baacb805792bfd31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! All good so far! :) On Fri, Oct 26, 2018 at 9:15 PM Tom Pusateri wrote: > > Thanks for the feedback! Comments inline. > > > On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: > > > > I'm in favor of advancing the document. I have a few editorial > comments: > > > > On Page 6: > > > > For example, if a user presses the "Print" > > button on their smartphone, and then leaves the phone showing the > > printer discovery screen until the phone goes to sleep, then the > > printer discovery screen should be automatically dismissed as the > > device goes to sleep. If the user does still intend to print, this > > will require them to press the "Print" button again when they wake > > their phone up. > > > > > > I don't think this is the right advice to give=E2=80=94it's not necessa= ry to > dismiss the UI. It always surprises me when a context switch results in > something in the UI changing without me changing it. The less surprisi= ng > behavior would be to simply stop doing these queries while the dialog isn= 't > showing. The dialog isn't showing when the phone is asleep. So maybe > this text would accomplish the same purpose without recommending a > particular UI flow? > > > > For example, if a user presses the "Print" button on their smartphone, > and then leaves the phone showing the printer discovery screen until the > phone goes to sleep, or switches > > to a different app, then the push subscription should (SHOULD?) be > discontinued. When the phone wakes up, > > or the user switches back to the application that is showing the print > > dialog, the subscription could be reinstated, perhaps after a brief wai= t > > to allow the user to dismiss the dialog if they no longer intend to > print. > > I agree that too much implementation info here is not needed. How about: > > (a) A subscription should only be active when there is a valid reason to > need live data (for example, an on-screen display is currently showing th= e > results to the user) and the subscription SHOULD be cancelled as soon as > the need for that data ends (for example, when the user dismisses that > display). Implementations may want to implement idle timeouts, so that if > the user ceases interacting with the device, the subscription is cancelle= d. > > > Section 3 says: > > > > Standard DNS Queries MAY be sent over a DNS Push Notification > connection, provided that these are queries for names falling within the > server's zone (the in the "_dns-push-tls._tcp." SRV record). > The RD (Recursion Desired) bit MUST be zero. If a query is received with > the RD bit set, matching records for names falling within the server's > zones should be returned with the RA (Recursion Available) bit clear. If > the query is for a name not in the server's zone, an error with RCODE > NOTAUTH (Not Authoritative) should be > > returned. > > > > Why is this? What if this is a hybrid authoritative/caching resolver? > Also, later on we do actually specify that this can work with the local > resolver. ISTM you could say this instead and capture what is necessary= : > > > > Standard DNS Queries MAY be sent over a DNS Push Notification > > connection. For any zone for which the server is authoritative, it > > > > MUST respond authoritatively for queries on names falling within > > that zone (e.g., the in the "_dns-push-tls._tcp." SRV > > record) both for DNS Push Notification queries and for normal DNS > > > > queries. For names for which the server is acting as a caching > > resolver, e.g. when the server is the local resolver, for any query > > for which it supports DNS Push Notifications, it MUST also support > > standard queries. > > That sounds better. I think the idea of subscriptions to a local resolver > came along later and this part didn=E2=80=99t get updated. > > > > > Section 4 says: > > > > In keeping with the more recent precedent, DNS Push Notification is > > defined only for TCP. DNS Push Notification clients MUST use DNS > > Stateful Operations (DSO) [ > > DSO] running over TLS over TCP [RFC7858]. > > > > But section 7 says: > > > > The Strict Privacy Usage Profile for DNS over TLS is strongly > > recommended for DNS Push Notifications as defined in "Usage Profiles > > for DNS over TLS and DNS over DTLS" [ > > RFC8310]. > > > > Which is it? :) > > Ok, I intended to go strict only since it was a new protocol. Here is the > new text in Section 7: > > The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Pus= h > Notifications as defined in "Usage Profiles for DNS over TLS and DNS over > DTLS". Cleartext connections for DNS Push Notifications are not > permissible. Since this is a new protocol, transistion mechanisms using t= he > Opportunistic Privacy profile are deemed unnecessary. > > > > > Section 5 says: > > > > Token bucket rate limiting schemes are also effective > > in providing fairness by a server across numerous client requests. > > > > > > [Citation Needed] > > > > Is there any reason to say this? > > No. Probably better to remove it. > > > > > DNS Push Notification clients and servers MUST support DSO, but (as > > stated in the DSO specification [ > > DSO > > ]) the server SHOULD NOT issue > > any DSO messages until after the client has first initiated an > > acknowledged DSO message of its own. A single server can support DN= S > > Queries, DNS Updates, and DNS Push Notifications (using DSO) on the > > same TCP port, and until the client has sent at least one DSO > > message, the server does not know what kind of client has connected > > to it. Once the client has indicated willingness to use DSO by > > sending one of its own, either side of the session may then initiate > > further DSO messages at any time. > > > > > > It's just reiterating what the DNS Stateful Operations document says, > and what was said previously about updates and so on. Less text better? > > I agree. > > Ok, that=E2=80=99s as far as I got tonight. More tomorrow. > > Thanks! > > Tom > > --000000000000baacb805792bfd31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!=C2=A0 All good so far! =C2=A0:)
<= div>
On Fri, Oct 26, 2018 at= 9:15 PM Tom Pusateri <pusateri@ba= ngj.com> wrote:

Thanks for the feedback! Comments inline.

> On Oct 26, 2018, at 5:28 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> I'm in favor of advancing the document.=C2=A0 =C2=A0I have a few e= ditorial comments:
>
> On Page 6:
>
>=C2=A0 =C2=A0 For example, if a user presses the "Print"
>=C2=A0 =C2=A0 button on their smartphone, and then leaves the phone sho= wing the
>=C2=A0 =C2=A0 printer discovery screen until the phone goes to sleep, t= hen the
>=C2=A0 =C2=A0 printer discovery screen should be automatically dismisse= d as the
>=C2=A0 =C2=A0 device goes to sleep.=C2=A0 If the user does still intend= to print, this
>=C2=A0 =C2=A0 will require them to press the "Print" button a= gain when they wake
>=C2=A0 =C2=A0 their phone up.
>
>
> I don't think this is the right advice to give=E2=80=94it's no= t necessary to dismiss the UI.=C2=A0 =C2=A0It always surprises me when a co= ntext switch results in something in the UI changing without me changing it= .=C2=A0 =C2=A0 The less surprising behavior would be to simply stop doing t= hese queries while the dialog isn't showing.=C2=A0 =C2=A0The dialog isn= 't showing when the phone is asleep.=C2=A0 =C2=A0So maybe this text wou= ld accomplish the same purpose without recommending a particular UI flow? >
> For example, if a user presses the "Print" button on their s= martphone, and then leaves the phone showing the printer discovery screen u= ntil the phone goes to sleep, or switches
> to a different app, then the push subscription should (SHOULD?) be dis= continued. When the phone wakes up,
> or the user switches back to the application that is showing the print=
> dialog, the subscription could be reinstated, perhaps after a brief wa= it
> to allow the user to dismiss the dialog if they no longer intend to pr= int.

I agree that too much implementation info here is not needed. How about:
(a) A subscription should only be active when there is a valid reason to ne= ed live data (for example, an on-screen display is currently showing the re= sults to the user) and the subscription SHOULD be cancelled as soon as the = need for that data ends (for example, when the user dismisses that display)= . Implementations may want to implement idle timeouts, so that if the user = ceases interacting with the device, the subscription is cancelled.

> Section 3 says:
>
> Standard DNS Queries MAY be sent over a DNS Push Notification connecti= on, provided that these are queries for names falling within the server'= ;s zone (the <zone> in the "_dns-push-tls._tcp.<zone>"= ; SRV record). The RD (Recursion Desired) bit MUST be zero. If a query is r= eceived with the RD bit set, matching records for names falling within the = server's zones should be returned with the RA (Recursion Available) bit= clear. If the query is for a name not in the server's zone, an error w= ith RCODE NOTAUTH (Not Authoritative) should be
>=C2=A0 =C2=A0 returned.
>
> Why is this?=C2=A0 =C2=A0What if this is a hybrid authoritative/cachin= g resolver?=C2=A0 =C2=A0Also, later on we do actually specify that this can= work with the local resolver.=C2=A0 =C2=A0ISTM you could say this instead = and capture what is necessary:
>
>=C2=A0 =C2=A0 Standard DNS Queries MAY be sent over a DNS Push Notifica= tion
>=C2=A0 =C2=A0 connection.=C2=A0 =C2=A0For any zone for which the server= is authoritative, it
>
>=C2=A0 =C2=A0 MUST respond authoritatively for queries on names falling= within
>=C2=A0 =C2=A0 that zone (e.g., the <zone> in the "_dns-push-= tls._tcp.<zone>" SRV
>=C2=A0 =C2=A0 record) both for DNS Push Notification queries and for no= rmal DNS
>
>=C2=A0 =C2=A0 queries.=C2=A0 =C2=A0For names for which the server is ac= ting as a caching
>=C2=A0 =C2=A0 resolver, e.g. when the server is the local resolver, for= any query
>=C2=A0 =C2=A0 for which it supports DNS Push Notifications, it MUST als= o support
>=C2=A0 =C2=A0 standard queries.

That sounds better. I think the idea of subscriptions to a local resolver c= ame along later and this part didn=E2=80=99t get updated.

>
> Section 4 says:
>
>=C2=A0 =C2=A0 In keeping with the more recent precedent, DNS Push Notif= ication is
>=C2=A0 =C2=A0 defined only for TCP.=C2=A0 DNS Push Notification clients= MUST use DNS
>=C2=A0 =C2=A0 Stateful Operations (DSO) [
> DSO] running over TLS over TCP [RFC7858].
>
> But section 7 says:
>
>=C2=A0 =C2=A0 The Strict Privacy Usage Profile for DNS over TLS is stro= ngly
>=C2=A0 =C2=A0 recommended for DNS Push Notifications as defined in &quo= t;Usage Profiles
>=C2=A0 =C2=A0 for DNS over TLS and DNS over DTLS" [
> RFC8310].
>
> Which is it?=C2=A0 =C2=A0:)

Ok, I intended to go strict only since it was a new protocol. Here is the n= ew text in Section 7:

The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Push = Notifications as defined in "Usage Profiles for DNS over TLS and DNS o= ver DTLS". Cleartext connections for DNS Push Notifications are not pe= rmissible. Since this is a new protocol, transistion mechanisms using the O= pportunistic Privacy profile are deemed unnecessary.

>
> Section 5 says:
>
>=C2=A0 =C2=A0 Token bucket rate limiting schemes are also effective
>=C2=A0 =C2=A0 in providing fairness by a server across numerous client = requests.
>
>
> [Citation Needed]
>
> Is there any reason to say this?

No. Probably better to remove it.

>
>=C2=A0 =C2=A0 DNS Push Notification clients and servers MUST support DS= O, but (as
>=C2=A0 =C2=A0 stated in the DSO specification [
> DSO
> ]) the server SHOULD NOT issue
>=C2=A0 =C2=A0 any DSO messages until after the client has first initiat= ed an
>=C2=A0 =C2=A0 acknowledged DSO message of its own.=C2=A0 A single serve= r can support DNS
>=C2=A0 =C2=A0 Queries, DNS Updates, and DNS Push Notifications (using D= SO) on the
>=C2=A0 =C2=A0 same TCP port, and until the client has sent at least one= DSO
>=C2=A0 =C2=A0 message, the server does not know what kind of client has= connected
>=C2=A0 =C2=A0 to it.=C2=A0 Once the client has indicated willingness to= use DSO by
>=C2=A0 =C2=A0 sending one of its own, either side of the session may th= en initiate
>=C2=A0 =C2=A0 further DSO messages at any time.
>
>
> It's just reiterating what the DNS Stateful Operations document sa= ys, and what was said previously about updates and so on.=C2=A0 =C2=A0Less = text better?

I agree.

Ok, that=E2=80=99s as far as I got tonight. More tomorrow.

Thanks!

Tom

--000000000000baacb805792bfd31-- From nobody Sun Oct 28 18:48:26 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BAC126F72 for ; Sun, 28 Oct 2018 18:48:24 -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 SAVHjzctLJtM for ; Sun, 28 Oct 2018 18:48:21 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 443A5124C04 for ; Sun, 28 Oct 2018 18:48:21 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id e2-v6so5896572edn.2 for ; Sun, 28 Oct 2018 18:48: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=/3D9lA4J25Em6WLJZOUK1jTAlc6b21A+D8e5Sriknrg=; b=YF1Qi3tD3KHjgSXiKPdl7GGB4UTpyvn7492q1aq9+T3O10vNVqhwfw0o9fMU1wHBS7 v4GvZ7ciiso2V7dq4RPCWnctjna5rL7h5Pf9ITCDHPCIBzYxj+83aagJsDTmX1rV+0zJ gDQ5nuFrl0oAGq/AMOjEWvMO8ItcGbiINFZOsJJRvBEaV8zPfd4s+o282/eRYX30ISoQ JF4uS8ZuJEzh6flN21BRf1zc+V4mjZkC0Umd08254Hg5AkiFkmMiyTWYxaHtTSUsvflh aCjxs0T6TocEtznz4BTaFsQSt8MZl5tJCd9wiy4N3TxFBpQzCstijqKN7INPcZ9DbIIt +gYg== 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=/3D9lA4J25Em6WLJZOUK1jTAlc6b21A+D8e5Sriknrg=; b=n7rGI8d93tW/B17kqaX6vXsUNYKm5uPeQvunB1xpyxkg8sPRkslNfO4pZskSGKK6xr /U9PdNYyTt0SiYKUDh9WEQAGI3ZoTT2JysnuGbR3S4jVDu4YNveT05AzWb2YVE8Ovm5L q/G8WTOqJ2RaV5MwB/XaT0FfoGIQ114Odd6NnS+dXLoK9UAze/dRcAe3cUiDOEPyl3iA b2kcEkOtfBFroXYQWu90efIJ8DXVoG88HVAQkpcheRwZab8R0mwGYhNda306NdJnZgv0 V9MHH5EvizT6sU1QpSe/Pa+3Xriu4e23AMSuvQD4v+Bt93JjkvtiP6pLmYSta500eM7x yiEA== X-Gm-Message-State: AGRZ1gI3uXkhRrpAsx4SvwLEpE3kzylPDKu0v08sOEpW30jsgtnn4L3a ccojc3iCkz3/+31FpK8xJP6X7pixUTRI7ULVhVPgjw== X-Google-Smtp-Source: AJdET5epu7YkHLLUaGkLbNVBXll4nsYtaRtNuM+LQ1eST4BzsZ/4Vs6yzXl22ReKiZ7obcBWikl7reBqBikxuNhbslY= X-Received: by 2002:a17:906:b799:: with SMTP id dt25-v6mr4389684ejb.217.1540777699665; Sun, 28 Oct 2018 18:48:19 -0700 (PDT) MIME-Version: 1.0 References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> In-Reply-To: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> From: Lanlan Pan Date: Sun, 28 Oct 2018 21:48:07 -0400 Message-ID: To: Christian Huitema Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000776be105795443a0" Archived-At: Subject: Re: [dnssd] Next steps for privacy discovery 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, 29 Oct 2018 01:48:24 -0000 --000000000000776be105795443a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christian Huitema =E4=BA=8E2018=E5=B9=B410=E6=9C=8826= =E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=883:09=E5=86=99=E9=81=93=EF=BC= =9A > With some prodding from David and Barbara, I resubmitted the DNSSD > Privacy and Pairing drafts before the Bangkok meeting. The changes are: > > * For both drafts, add reference to the privacy requirement draft and to > the scaling draft, > > * For both drafts, add a short paragraph in the intro stating that > things might change based on the scaling analysis, > > * For the privacy draft, remove the requirement analysis part and > replace it by a reference to the requirement draft. > > David is prodding me to write a complete revision of the privacy draft, > using the "shared public key" approach, which has very good scaling > capabilities and reasonably robust resilience to attacks. It is a bit > different from the draft that Bob Bradley sent, and I will comment on tha= t > later. I could not submitted a revised discovery proposal before the dead > line, but here are the broad lines of what I would do: > > 1) Server has a public key, which is "somewhat secret" -- it is only > provided to authorized clients and they are expected to keep it secret. > > 2) Single announcement per server of the form nonce|proof, where the > nonce is a "predictable nonce" computed as a hash of quantized time and > secret public key. > > 3) Clients do a search for the nonce, just like in the current spec, but > there is only one nonce per server, so the client will get exactly one > response. > > 4) If we kept the current "two phase" structure, use a TLS protocol > extension to demonstrate knowledge of the server's public key in the > client hello. I think we can build on the work done for SNI encryption, > which would fit quite well. > I wonder if we could consider about use tls psk (pre-shared key) ? server can assign different key to different client. > 5) We may consider having a different nonce for each available service, > e.g. have the announcement computed as hash of quantized time, service > type and secret public key. This would allow for a single phase solution. > > 6) We may also have the service name used as a proof, e.g. encoding of > nonce and service name with the server's private key. > > 7) We need to say something about protecting the service connections > from clients to server. DNSSD privacy would not be that much useful if > the clear text data on the service connection revealed the identity of > client or server. I think a combination of SNI encryption and TLS 1.3 > would work, but that may be extra work. > > 8) We also need to recommend randomized host names for the A/AAAA > records of the servers, otherwise there is also a big leak. > > Some of the complexity in the DNSSD approach comes from a desire to fit > into the existing DNSSD formats. This leads to some tricks like Base64 > encoding of nonce, time stamps and proofs so they fit in existing > fields like service type or instance name. Bob's draft jettisons DNSSD > compatibility and defines a new binary format. That is definitely > cleaner, but there is a trade-off: a new protocol implies that we cannot > reuse the DNSSD server infrastructure. It would be interesting to gauge > the WG consensus on that tradeoff. > > The other big difference between Bob's draft and the evolving proposal > is the use of trial decryption. In Bob's approach, clients send probes > that the server tries to decrypt by using the public keys of various > registered peers or friends. This has scaling issues similar to the > pairwise keys that we relied on in our first drafts. After discussions, > we grew very concerned with these scaling issues and the > corresponding potential for DOS attacks. We instead evolved towards > a system of "predictable nonces". > > The predictable nonces are a tradeoff between privacy and performance. > Predictable nonces can be precomputed by the server, which reduces the > processing cost and also limits the potential of DOS attacks. But then, > all authorized clients of a server can generate the same predictable > nonces, and thus all authorized clients can detect the presence > of other authorized clients. This reduces privacy somewhat, although not > necessarily by a whole lot. All authorized clients can discover the serve= r, > and thus retrieve its IP address. Network level analysis can then reveal > which clients are also connecting to that server. This means that the > information > potentially leaked by the predictable nonce is also available at a lower > layer. I think that the trade-off is thus between a minor privacy leak an= d > a significant performance gain, but of course other WG members may have a > different analysis. It would be interesting to gauge WG consensus on that > subject. > > Looking forward to the debates in Bangkok! > > -- Christian Huitema > > > > > > > > -- Christian Huitema > > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --000000000000776be105795443a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


With some prodding from David and Barbara, I resubmitted the = DNSSD
Privacy and Pairing drafts before the Bangkok meeting. The changes are:

* For both drafts, add reference to the privacy requirement draft and to the scaling draft,

* For both drafts, add a short paragraph in the intro stating that
things might change based on the scaling analysis,

* For the privacy draft, remove the requirement analysis part and
replace it by a reference to the requirement draft.

David is prodding me to write a complete revision of the privacy draft,
using the "shared public key" approach, which has very good scali= ng
capabilities and reasonably robust resilience to attacks. It is a bit
different from the draft that Bob Bradley sent, and I will comment on that<= br> later. I could not submitted a revised discovery proposal before the dead line, but here are the broad lines of what I would do:

1) Server has a public key, which is "somewhat secret" -- it is o= nly
provided to authorized clients and they are expected to keep it secret.

2) Single announcement per server of the form nonce|proof, where the
nonce is a "predictable nonce" computed as a hash of quantized ti= me and
secret public key.

3) Clients do a search for the nonce, just like in the current spec, but there is only one nonce per server, so the client will get exactly one
response.

4) If we kept the current "two phase" structure, use a TLS protoc= ol
extension to demonstrate knowledge of the server's public key in the client hello. I think we can build on the work done for SNI encryption,
which would fit quite well.


5) We may consider having a different nonce for each available service,
e.g. have the announcement computed as hash of quantized time, service
type and secret public key. This would allow for a single phase solution.
6) We may also have the service name used as a proof, e.g. encoding of
nonce and service name with the server's private key.

7) We need to say something about protecting the service connections
from clients to server. DNSSD privacy would not be that much useful if
the clear text data on the service connection revealed the identity of
client or server. I think a combination of SNI encryption and TLS 1.3
would work, but that may be extra work.

8) We also need to recommend randomized host names for the A/AAAA
records of the servers, otherwise there is also a big leak.

Some of the complexity in the DNSSD approach comes from a desire to fit
into the existing DNSSD formats. This leads to some tricks like Base64
encoding of nonce, time stamps and proofs so they fit in existing
fields like service type or instance name. Bob's draft jettisons DNSSD<= br> compatibility and defines a new binary format. That is definitely
cleaner, but there is a trade-off: a new protocol implies that we cannot reuse the DNSSD server infrastructure. It would be interesting to gauge
the WG consensus on that tradeoff.

The other big difference between Bob's draft and the evolving proposal<= br> is the use of trial decryption. In Bob's approach, clients send probes<= br> that the server tries to decrypt by using the public keys of various
registered peers or friends. This has scaling issues similar to the
pairwise keys that we relied on in our first drafts. After discussions,
we grew very concerned with these scaling issues and the
corresponding potential for DOS attacks. We instead evolved towards
a system of "predictable nonces".

The predictable nonces are a tradeoff between privacy and performance.
Predictable nonces can be precomputed by the server, which reduces the
processing cost and also limits the potential of DOS attacks. But then,
all authorized clients of a server can generate the same predictable
nonces, and thus all authorized clients can detect the presence
of other authorized clients. This reduces privacy somewhat, although not necessarily by a whole lot. All authorized clients can discover the server,=
and thus retrieve its IP address. Network level analysis can then reveal which clients are also connecting to that server. This means that the infor= mation
potentially leaked by the predictable nonce is also available at a lower layer. I think that the trade-off is thus between a minor privacy leak and<= br> a significant performance gain, but of course other WG members may have a different analysis. It would be interesting to gauge WG consensus on that subject.

Looking forward to the debates in Bangkok!

-- Christian Huitema
=C2=A0






=C2=A0-- Christian Huitema




_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--
=E8=87=B4=E7=A4=BC=C2= =A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--000000000000776be105795443a0-- From nobody Mon Oct 29 07:34:58 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755E8128BCC for ; Mon, 29 Oct 2018 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 zYd5ZvxZSjbU for ; Mon, 29 Oct 2018 07:34:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C346130E29 for ; Mon, 29 Oct 2018 07:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9234; q=dns/txt; s=iport; t=1540823693; x=1542033293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cg79GSHlVGOffzuHExinUtaPW7Z4Xt1P1U8ozZ/Mb6w=; b=ig+WE+bQerjpIWl3QHdBH4XHqAxHENBGrkab//MQh8tdwfN5p4IFVVV7 ch/hsimLXjIn2L9STsluaYi2s2/NykX1UaAfIFORWCkYQ+7+xTwZ/TYsC y8qKySNvDxF++XCNyPkuI+fjfVeN5+CqRQrCcIojuuZvLoWjc9BiGsBkt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAABYGddb/5BdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggSBZSgKg2uUL4FoJZkaCwEBLIRAAhe?= =?us-ascii?q?DFSE3Cg0BAwEBAgEBAm0ohToBAQEBAgEdBhFFEAIBCBgCAgkdAgICMBUQAgQ?= =?us-ascii?q?OBYMhgXoIqB+BLooTgQuKXBeBQT+BEScME4JMhGiDGjGCJgKIWYIMg3uBRIR?= =?us-ascii?q?IiUlUCQKRAhiQR5Z1AhEUgSYzIoFVcBVlAYJBgiYXjhpvgSiJMASBKgGBHgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.54,440,1534809600"; d="scan'208";a="470896067" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2018 14:34:52 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9TEYqF2031893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Oct 2018 14:34:52 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 09:34:51 -0500 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 09:34:51 -0500 From: "Jan Komissar (jkomissa)" To: Tom Pusateri CC: Stuart Cheshire , Tim Wicinski , dnssd , David Schinazi , Ted Lemon Thread-Topic: [dnssd] Working group last call for draft-ietf-dnssd-push Thread-Index: AQHUWFROXVpV2MKdXUmWQfXaA3KbEKUoeOaAgAMGG4CABwnUgIAAP4EAgAPA3QA= Date: Mon, 29 Oct 2018 14:34:51 +0000 Message-ID: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> In-Reply-To: <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.100] Content-Type: text/plain; charset="utf-8" Content-ID: <947D9A4905C5EA40B1C6C22EE7F52D9F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 29 Oct 2018 14:34:56 -0000 SGkgVG9tLA0KDQpBbm90aGVyIHRoaW5nIEkgbm90aWNlZDogSW4gdGhlIERTTyBzcGVjIChkcmFm dC1pZXRmLWRuc29wLXNlc3Npb24tc2lnbmFsLTE2KSwgaW4gc2VjdGlvbiA4LjIgIChwLjUxKSwg dGhlcmUgaXMgYSB0YWJsZSBpbmRpY2F0aW5nIHByb3BlciB1c2FnZSBvZiB0aGUgdmFyaW91cyBU TFZzIGluIHRoZSBzcGVjIHdpdGggYSByZWNvbW1lbmRhdGlvbiB0byBkbyB0aGUgc2FtZSBmb3Ig ZnV0dXJlIFRMViBkZWZpbml0aW9ucy4gSXQgbWlnaHQgYmUgZ29vZCB0byBhZGQgdGhhdCB0byB0 aGUgUHVzaCBOb3RpZmljYXRpb24gc3BlYyBhcyB3ZWxsLg0KDQpUaGFua3MsDQoNCkphbi4NCg0K 77u/T24gMTAvMjYvMTgsIDk6MTUgUE0sICJUb20gUHVzYXRlcmkiIDxwdXNhdGVyaUBiYW5nai5j b20+IHdyb3RlOg0KDQogICAgDQogICAgVGhhbmtzIGZvciB0aGUgZmVlZGJhY2shIENvbW1lbnRz IGlubGluZS4NCiAgICANCiAgICA+IE9uIE9jdCAyNiwgMjAxOCwgYXQgNToyOCBQTSwgVGVkIExl bW9uIDxtZWxsb25AZnVndWUuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gSSdtIGluIGZhdm9y IG9mIGFkdmFuY2luZyB0aGUgZG9jdW1lbnQuICAgSSBoYXZlIGEgZmV3IGVkaXRvcmlhbCBjb21t ZW50czoNCiAgICA+IA0KICAgID4gT24gUGFnZSA2Og0KICAgID4gDQogICAgPiAgICBGb3IgZXhh bXBsZSwgaWYgYSB1c2VyIHByZXNzZXMgdGhlICJQcmludCINCiAgICA+ICAgIGJ1dHRvbiBvbiB0 aGVpciBzbWFydHBob25lLCBhbmQgdGhlbiBsZWF2ZXMgdGhlIHBob25lIHNob3dpbmcgdGhlDQog ICAgPiAgICBwcmludGVyIGRpc2NvdmVyeSBzY3JlZW4gdW50aWwgdGhlIHBob25lIGdvZXMgdG8g c2xlZXAsIHRoZW4gdGhlDQogICAgPiAgICBwcmludGVyIGRpc2NvdmVyeSBzY3JlZW4gc2hvdWxk IGJlIGF1dG9tYXRpY2FsbHkgZGlzbWlzc2VkIGFzIHRoZQ0KICAgID4gICAgZGV2aWNlIGdvZXMg dG8gc2xlZXAuICBJZiB0aGUgdXNlciBkb2VzIHN0aWxsIGludGVuZCB0byBwcmludCwgdGhpcw0K ICAgID4gICAgd2lsbCByZXF1aXJlIHRoZW0gdG8gcHJlc3MgdGhlICJQcmludCIgYnV0dG9uIGFn YWluIHdoZW4gdGhleSB3YWtlDQogICAgPiAgICB0aGVpciBwaG9uZSB1cC4NCiAgICA+IA0KICAg ID4gDQogICAgPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIHJpZ2h0IGFkdmljZSB0byBnaXZl 4oCUaXQncyBub3QgbmVjZXNzYXJ5IHRvIGRpc21pc3MgdGhlIFVJLiAgIEl0IGFsd2F5cyBzdXJw cmlzZXMgbWUgd2hlbiBhIGNvbnRleHQgc3dpdGNoIHJlc3VsdHMgaW4gc29tZXRoaW5nIGluIHRo ZSBVSSBjaGFuZ2luZyB3aXRob3V0IG1lIGNoYW5naW5nIGl0LiAgICBUaGUgbGVzcyBzdXJwcmlz aW5nIGJlaGF2aW9yIHdvdWxkIGJlIHRvIHNpbXBseSBzdG9wIGRvaW5nIHRoZXNlIHF1ZXJpZXMg d2hpbGUgdGhlIGRpYWxvZyBpc24ndCBzaG93aW5nLiAgIFRoZSBkaWFsb2cgaXNuJ3Qgc2hvd2lu ZyB3aGVuIHRoZSBwaG9uZSBpcyBhc2xlZXAuICAgU28gbWF5YmUgdGhpcyB0ZXh0IHdvdWxkIGFj Y29tcGxpc2ggdGhlIHNhbWUgcHVycG9zZSB3aXRob3V0IHJlY29tbWVuZGluZyBhIHBhcnRpY3Vs YXIgVUkgZmxvdz8NCiAgICA+IA0KICAgID4gRm9yIGV4YW1wbGUsIGlmIGEgdXNlciBwcmVzc2Vz IHRoZSAiUHJpbnQiIGJ1dHRvbiBvbiB0aGVpciBzbWFydHBob25lLCBhbmQgdGhlbiBsZWF2ZXMg dGhlIHBob25lIHNob3dpbmcgdGhlIHByaW50ZXIgZGlzY292ZXJ5IHNjcmVlbiB1bnRpbCB0aGUg cGhvbmUgZ29lcyB0byBzbGVlcCwgb3Igc3dpdGNoZXMNCiAgICA+IHRvIGEgZGlmZmVyZW50IGFw cCwgdGhlbiB0aGUgcHVzaCBzdWJzY3JpcHRpb24gc2hvdWxkIChTSE9VTEQ/KSBiZSBkaXNjb250 aW51ZWQuIFdoZW4gdGhlIHBob25lIHdha2VzIHVwLA0KICAgID4gb3IgdGhlIHVzZXIgc3dpdGNo ZXMgYmFjayB0byB0aGUgYXBwbGljYXRpb24gdGhhdCBpcyBzaG93aW5nIHRoZSBwcmludA0KICAg ID4gZGlhbG9nLCB0aGUgc3Vic2NyaXB0aW9uIGNvdWxkIGJlIHJlaW5zdGF0ZWQsIHBlcmhhcHMg YWZ0ZXIgYSBicmllZiB3YWl0DQogICAgPiB0byBhbGxvdyB0aGUgdXNlciB0byBkaXNtaXNzIHRo ZSBkaWFsb2cgaWYgdGhleSBubyBsb25nZXIgaW50ZW5kIHRvIHByaW50Lg0KICAgIA0KICAgIEkg YWdyZWUgdGhhdCB0b28gbXVjaCBpbXBsZW1lbnRhdGlvbiBpbmZvIGhlcmUgaXMgbm90IG5lZWRl ZC4gSG93IGFib3V0Og0KICAgIA0KICAgIChhKSBBIHN1YnNjcmlwdGlvbiBzaG91bGQgb25seSBi ZSBhY3RpdmUgd2hlbiB0aGVyZSBpcyBhIHZhbGlkIHJlYXNvbiB0byBuZWVkIGxpdmUgZGF0YSAo Zm9yIGV4YW1wbGUsIGFuIG9uLXNjcmVlbiBkaXNwbGF5IGlzIGN1cnJlbnRseSBzaG93aW5nIHRo ZSByZXN1bHRzIHRvIHRoZSB1c2VyKSBhbmQgdGhlIHN1YnNjcmlwdGlvbiBTSE9VTEQgYmUgY2Fu Y2VsbGVkIGFzIHNvb24gYXMgdGhlIG5lZWQgZm9yIHRoYXQgZGF0YSBlbmRzIChmb3IgZXhhbXBs ZSwgd2hlbiB0aGUgdXNlciBkaXNtaXNzZXMgdGhhdCBkaXNwbGF5KS4gSW1wbGVtZW50YXRpb25z IG1heSB3YW50IHRvIGltcGxlbWVudCBpZGxlIHRpbWVvdXRzLCBzbyB0aGF0IGlmIHRoZSB1c2Vy IGNlYXNlcyBpbnRlcmFjdGluZyB3aXRoIHRoZSBkZXZpY2UsIHRoZSBzdWJzY3JpcHRpb24gaXMg Y2FuY2VsbGVkLg0KICAgIA0KICAgID4gU2VjdGlvbiAzIHNheXM6DQogICAgPiANCiAgICA+IFN0 YW5kYXJkIEROUyBRdWVyaWVzIE1BWSBiZSBzZW50IG92ZXIgYSBETlMgUHVzaCBOb3RpZmljYXRp b24gY29ubmVjdGlvbiwgcHJvdmlkZWQgdGhhdCB0aGVzZSBhcmUgcXVlcmllcyBmb3IgbmFtZXMg ZmFsbGluZyB3aXRoaW4gdGhlIHNlcnZlcidzIHpvbmUgKHRoZSA8em9uZT4gaW4gdGhlICJfZG5z LXB1c2gtdGxzLl90Y3AuPHpvbmU+IiBTUlYgcmVjb3JkKS4gVGhlIFJEIChSZWN1cnNpb24gRGVz aXJlZCkgYml0IE1VU1QgYmUgemVyby4gSWYgYSBxdWVyeSBpcyByZWNlaXZlZCB3aXRoIHRoZSBS RCBiaXQgc2V0LCBtYXRjaGluZyByZWNvcmRzIGZvciBuYW1lcyBmYWxsaW5nIHdpdGhpbiB0aGUg c2VydmVyJ3Mgem9uZXMgc2hvdWxkIGJlIHJldHVybmVkIHdpdGggdGhlIFJBIChSZWN1cnNpb24g QXZhaWxhYmxlKSBiaXQgY2xlYXIuIElmIHRoZSBxdWVyeSBpcyBmb3IgYSBuYW1lIG5vdCBpbiB0 aGUgc2VydmVyJ3Mgem9uZSwgYW4gZXJyb3Igd2l0aCBSQ09ERSBOT1RBVVRIIChOb3QgQXV0aG9y aXRhdGl2ZSkgc2hvdWxkIGJlIA0KICAgID4gICAgcmV0dXJuZWQuDQogICAgPiANCiAgICA+IFdo eSBpcyB0aGlzPyAgIFdoYXQgaWYgdGhpcyBpcyBhIGh5YnJpZCBhdXRob3JpdGF0aXZlL2NhY2hp bmcgcmVzb2x2ZXI/ICAgQWxzbywgbGF0ZXIgb24gd2UgZG8gYWN0dWFsbHkgc3BlY2lmeSB0aGF0 IHRoaXMgY2FuIHdvcmsgd2l0aCB0aGUgbG9jYWwgcmVzb2x2ZXIuICAgSVNUTSB5b3UgY291bGQg c2F5IHRoaXMgaW5zdGVhZCBhbmQgY2FwdHVyZSB3aGF0IGlzIG5lY2Vzc2FyeToNCiAgICA+IA0K ICAgID4gICAgU3RhbmRhcmQgRE5TIFF1ZXJpZXMgTUFZIGJlIHNlbnQgb3ZlciBhIEROUyBQdXNo IE5vdGlmaWNhdGlvbg0KICAgID4gICAgY29ubmVjdGlvbi4gICBGb3IgYW55IHpvbmUgZm9yIHdo aWNoIHRoZSBzZXJ2ZXIgaXMgYXV0aG9yaXRhdGl2ZSwgaXQNCiAgICA+IA0KICAgID4gICAgTVVT VCByZXNwb25kIGF1dGhvcml0YXRpdmVseSBmb3IgcXVlcmllcyBvbiBuYW1lcyBmYWxsaW5nIHdp dGhpbg0KICAgID4gICAgdGhhdCB6b25lIChlLmcuLCB0aGUgPHpvbmU+IGluIHRoZSAiX2Rucy1w dXNoLXRscy5fdGNwLjx6b25lPiIgU1JWDQogICAgPiAgICByZWNvcmQpIGJvdGggZm9yIEROUyBQ dXNoIE5vdGlmaWNhdGlvbiBxdWVyaWVzIGFuZCBmb3Igbm9ybWFsIEROUw0KICAgID4gDQogICAg PiAgICBxdWVyaWVzLiAgIEZvciBuYW1lcyBmb3Igd2hpY2ggdGhlIHNlcnZlciBpcyBhY3Rpbmcg YXMgYSBjYWNoaW5nDQogICAgPiAgICByZXNvbHZlciwgZS5nLiB3aGVuIHRoZSBzZXJ2ZXIgaXMg dGhlIGxvY2FsIHJlc29sdmVyLCBmb3IgYW55IHF1ZXJ5DQogICAgPiAgICBmb3Igd2hpY2ggaXQg c3VwcG9ydHMgRE5TIFB1c2ggTm90aWZpY2F0aW9ucywgaXQgTVVTVCBhbHNvIHN1cHBvcnQNCiAg ICA+ICAgIHN0YW5kYXJkIHF1ZXJpZXMuDQogICAgDQogICAgVGhhdCBzb3VuZHMgYmV0dGVyLiBJ IHRoaW5rIHRoZSBpZGVhIG9mIHN1YnNjcmlwdGlvbnMgdG8gYSBsb2NhbCByZXNvbHZlciBjYW1l IGFsb25nIGxhdGVyIGFuZCB0aGlzIHBhcnQgZGlkbuKAmXQgZ2V0IHVwZGF0ZWQuDQogICAgDQog ICAgPiANCiAgICA+IFNlY3Rpb24gNCBzYXlzOg0KICAgID4gDQogICAgPiAgICBJbiBrZWVwaW5n IHdpdGggdGhlIG1vcmUgcmVjZW50IHByZWNlZGVudCwgRE5TIFB1c2ggTm90aWZpY2F0aW9uIGlz DQogICAgPiAgICBkZWZpbmVkIG9ubHkgZm9yIFRDUC4gIEROUyBQdXNoIE5vdGlmaWNhdGlvbiBj bGllbnRzIE1VU1QgdXNlIEROUw0KICAgID4gICAgU3RhdGVmdWwgT3BlcmF0aW9ucyAoRFNPKSBb DQogICAgPiBEU09dIHJ1bm5pbmcgb3ZlciBUTFMgb3ZlciBUQ1AgW1JGQzc4NThdLg0KICAgID4g DQogICAgPiBCdXQgc2VjdGlvbiA3IHNheXM6DQogICAgPiANCiAgICA+ICAgIFRoZSBTdHJpY3Qg UHJpdmFjeSBVc2FnZSBQcm9maWxlIGZvciBETlMgb3ZlciBUTFMgaXMgc3Ryb25nbHkNCiAgICA+ ICAgIHJlY29tbWVuZGVkIGZvciBETlMgUHVzaCBOb3RpZmljYXRpb25zIGFzIGRlZmluZWQgaW4g IlVzYWdlIFByb2ZpbGVzDQogICAgPiAgICBmb3IgRE5TIG92ZXIgVExTIGFuZCBETlMgb3ZlciBE VExTIiBbDQogICAgPiBSRkM4MzEwXS4NCiAgICA+IA0KICAgID4gV2hpY2ggaXMgaXQ/ICAgOikN CiAgICANCiAgICBPaywgSSBpbnRlbmRlZCB0byBnbyBzdHJpY3Qgb25seSBzaW5jZSBpdCB3YXMg YSBuZXcgcHJvdG9jb2wuIEhlcmUgaXMgdGhlIG5ldyB0ZXh0IGluIFNlY3Rpb24gNzoNCiAgICAN CiAgICBUaGUgU3RyaWN0IFByaXZhY3kgVXNhZ2UgUHJvZmlsZSBmb3IgRE5TIG92ZXIgVExTIGlz IFJFUVVJUkVEIGZvciBETlMgUHVzaCBOb3RpZmljYXRpb25zIGFzIGRlZmluZWQgaW4gIlVzYWdl IFByb2ZpbGVzIGZvciBETlMgb3ZlciBUTFMgYW5kIEROUyBvdmVyIERUTFMiLiBDbGVhcnRleHQg Y29ubmVjdGlvbnMgZm9yIEROUyBQdXNoIE5vdGlmaWNhdGlvbnMgYXJlIG5vdCBwZXJtaXNzaWJs ZS4gU2luY2UgdGhpcyBpcyBhIG5ldyBwcm90b2NvbCwgdHJhbnNpc3Rpb24gbWVjaGFuaXNtcyB1 c2luZyB0aGUgT3Bwb3J0dW5pc3RpYyBQcml2YWN5IHByb2ZpbGUgYXJlIGRlZW1lZCB1bm5lY2Vz c2FyeS4NCiAgICANCiAgICA+IA0KICAgID4gU2VjdGlvbiA1IHNheXM6DQogICAgPiANCiAgICA+ ICAgIFRva2VuIGJ1Y2tldCByYXRlIGxpbWl0aW5nIHNjaGVtZXMgYXJlIGFsc28gZWZmZWN0aXZl DQogICAgPiAgICBpbiBwcm92aWRpbmcgZmFpcm5lc3MgYnkgYSBzZXJ2ZXIgYWNyb3NzIG51bWVy b3VzIGNsaWVudCByZXF1ZXN0cy4NCiAgICA+IA0KICAgID4gDQogICAgPiBbQ2l0YXRpb24gTmVl ZGVkXQ0KICAgID4gDQogICAgPiBJcyB0aGVyZSBhbnkgcmVhc29uIHRvIHNheSB0aGlzPw0KICAg IA0KICAgIE5vLiBQcm9iYWJseSBiZXR0ZXIgdG8gcmVtb3ZlIGl0Lg0KICAgIA0KICAgID4gDQog ICAgPiAgICBETlMgUHVzaCBOb3RpZmljYXRpb24gY2xpZW50cyBhbmQgc2VydmVycyBNVVNUIHN1 cHBvcnQgRFNPLCBidXQgKGFzDQogICAgPiAgICBzdGF0ZWQgaW4gdGhlIERTTyBzcGVjaWZpY2F0 aW9uIFsNCiAgICA+IERTTw0KICAgID4gXSkgdGhlIHNlcnZlciBTSE9VTEQgTk9UIGlzc3VlDQog ICAgPiAgICBhbnkgRFNPIG1lc3NhZ2VzIHVudGlsIGFmdGVyIHRoZSBjbGllbnQgaGFzIGZpcnN0 IGluaXRpYXRlZCBhbg0KICAgID4gICAgYWNrbm93bGVkZ2VkIERTTyBtZXNzYWdlIG9mIGl0cyBv d24uICBBIHNpbmdsZSBzZXJ2ZXIgY2FuIHN1cHBvcnQgRE5TDQogICAgPiAgICBRdWVyaWVzLCBE TlMgVXBkYXRlcywgYW5kIEROUyBQdXNoIE5vdGlmaWNhdGlvbnMgKHVzaW5nIERTTykgb24gdGhl DQogICAgPiAgICBzYW1lIFRDUCBwb3J0LCBhbmQgdW50aWwgdGhlIGNsaWVudCBoYXMgc2VudCBh dCBsZWFzdCBvbmUgRFNPDQogICAgPiAgICBtZXNzYWdlLCB0aGUgc2VydmVyIGRvZXMgbm90IGtu b3cgd2hhdCBraW5kIG9mIGNsaWVudCBoYXMgY29ubmVjdGVkDQogICAgPiAgICB0byBpdC4gIE9u Y2UgdGhlIGNsaWVudCBoYXMgaW5kaWNhdGVkIHdpbGxpbmduZXNzIHRvIHVzZSBEU08gYnkNCiAg ICA+ICAgIHNlbmRpbmcgb25lIG9mIGl0cyBvd24sIGVpdGhlciBzaWRlIG9mIHRoZSBzZXNzaW9u IG1heSB0aGVuIGluaXRpYXRlDQogICAgPiAgICBmdXJ0aGVyIERTTyBtZXNzYWdlcyBhdCBhbnkg dGltZS4NCiAgICA+IA0KICAgID4gDQogICAgPiBJdCdzIGp1c3QgcmVpdGVyYXRpbmcgd2hhdCB0 aGUgRE5TIFN0YXRlZnVsIE9wZXJhdGlvbnMgZG9jdW1lbnQgc2F5cywgYW5kIHdoYXQgd2FzIHNh aWQgcHJldmlvdXNseSBhYm91dCB1cGRhdGVzIGFuZCBzbyBvbi4gICBMZXNzIHRleHQgYmV0dGVy Pw0KICAgIA0KICAgIEkgYWdyZWUuDQogICAgDQogICAgT2ssIHRoYXTigJlzIGFzIGZhciBhcyBJ IGdvdCB0b25pZ2h0LiBNb3JlIHRvbW9ycm93Lg0KICAgIA0KICAgIFRoYW5rcyENCiAgICANCiAg ICBUb20NCiAgICANCiAgICANCg0K From nobody Mon Oct 29 07:42:58 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2612F1A2 for ; Mon, 29 Oct 2018 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ijwRibq0zNZR for ; Mon, 29 Oct 2018 07:42:54 -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 20337128BCC for ; Mon, 29 Oct 2018 07:42:53 -0700 (PDT) Received: from [192.168.1.210] (66-190-152-116.dhcp.hckr.nc.charter.com [66.190.152.116]) (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 89C1B2129E; Mon, 29 Oct 2018 10:42:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Mon, 29 Oct 2018 10:42:51 -0400 Cc: Stuart Cheshire , Tim Wicinski , dnssd , Ted Lemon , David Schinazi Content-Transfer-Encoding: quoted-printable Message-Id: <3789E1FD-01A8-4356-A185-9AD1155C7F39@bangj.com> References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> To: "Jan Komissar (jkomissa)" Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 29 Oct 2018 14:42:57 -0000 Yes, be glad to add this.=20 Thanks! Tom > On Oct 29, 2018, at 10:34 AM, Jan Komissar (jkomissa) = wrote: >=20 > Hi Tom, >=20 > Another thing I noticed: In the DSO spec (draft-ietf-dnsop-session-signal-= 16), in section 8.2 (p.51), there is a table indicating proper usage of the= various TLVs in the spec with a recommendation to do the same for future TL= V definitions. It might be good to add that to the Push Notification spec as= well. >=20 > Thanks, >=20 > Jan. >=20 > =EF=BB=BFOn 10/26/18, 9:15 PM, "Tom Pusateri" wrote: >=20 >=20 > Thanks for the feedback! Comments inline. >=20 >> On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: >>=20 >> I'm in favor of advancing the document. I have a few editorial comments= : >>=20 >> On Page 6: >>=20 >> For example, if a user presses the "Print" >> button on their smartphone, and then leaves the phone showing the >> printer discovery screen until the phone goes to sleep, then the >> printer discovery screen should be automatically dismissed as the >> device goes to sleep. If the user does still intend to print, this >> will require them to press the "Print" button again when they wake >> their phone up. >>=20 >>=20 >> I don't think this is the right advice to give=E2=80=94it's not necessary= to dismiss the UI. It always surprises me when a context switch results i= n something in the UI changing without me changing it. The less surprisin= g behavior would be to simply stop doing these queries while the dialog isn'= t showing. The dialog isn't showing when the phone is asleep. So maybe t= his text would accomplish the same purpose without recommending a particular= UI flow? >>=20 >> For example, if a user presses the "Print" button on their smartphone, an= d then leaves the phone showing the printer discovery screen until the phone= goes to sleep, or switches >> to a different app, then the push subscription should (SHOULD?) be discon= tinued. When the phone wakes up, >> or the user switches back to the application that is showing the print >> dialog, the subscription could be reinstated, perhaps after a brief wait >> to allow the user to dismiss the dialog if they no longer intend to print= . >=20 > I agree that too much implementation info here is not needed. How about= : >=20 > (a) A subscription should only be active when there is a valid reason t= o need live data (for example, an on-screen display is currently showing the= results to the user) and the subscription SHOULD be cancelled as soon as th= e need for that data ends (for example, when the user dismisses that display= ). Implementations may want to implement idle timeouts, so that if the user c= eases interacting with the device, the subscription is cancelled. >=20 >> Section 3 says: >>=20 >> Standard DNS Queries MAY be sent over a DNS Push Notification connection,= provided that these are queries for names falling within the server's zone (= the in the "_dns-push-tls._tcp." SRV record). The RD (Recursion= Desired) bit MUST be zero. If a query is received with the RD bit set, matc= hing records for names falling within the server's zones should be returned w= ith the RA (Recursion Available) bit clear. If the query is for a name not i= n the server's zone, an error with RCODE NOTAUTH (Not Authoritative) should b= e=20 >> returned. >>=20 >> Why is this? What if this is a hybrid authoritative/caching resolver? = Also, later on we do actually specify that this can work with the local res= olver. ISTM you could say this instead and capture what is necessary: >>=20 >> Standard DNS Queries MAY be sent over a DNS Push Notification >> connection. For any zone for which the server is authoritative, it >>=20 >> MUST respond authoritatively for queries on names falling within >> that zone (e.g., the in the "_dns-push-tls._tcp." SRV >> record) both for DNS Push Notification queries and for normal DNS >>=20 >> queries. For names for which the server is acting as a caching >> resolver, e.g. when the server is the local resolver, for any query >> for which it supports DNS Push Notifications, it MUST also support >> standard queries. >=20 > That sounds better. I think the idea of subscriptions to a local resolv= er came along later and this part didn=E2=80=99t get updated. >=20 >>=20 >> Section 4 says: >>=20 >> In keeping with the more recent precedent, DNS Push Notification is >> defined only for TCP. DNS Push Notification clients MUST use DNS >> Stateful Operations (DSO) [ >> DSO] running over TLS over TCP [RFC7858]. >>=20 >> But section 7 says: >>=20 >> The Strict Privacy Usage Profile for DNS over TLS is strongly >> recommended for DNS Push Notifications as defined in "Usage Profiles >> for DNS over TLS and DNS over DTLS" [ >> RFC8310]. >>=20 >> Which is it? :) >=20 > Ok, I intended to go strict only since it was a new protocol. Here is t= he new text in Section 7: >=20 > The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS P= ush Notifications as defined in "Usage Profiles for DNS over TLS and DNS ove= r DTLS". Cleartext connections for DNS Push Notifications are not permissibl= e. Since this is a new protocol, transistion mechanisms using the Opportunis= tic Privacy profile are deemed unnecessary. >=20 >>=20 >> Section 5 says: >>=20 >> Token bucket rate limiting schemes are also effective >> in providing fairness by a server across numerous client requests. >>=20 >>=20 >> [Citation Needed] >>=20 >> Is there any reason to say this? >=20 > No. Probably better to remove it. >=20 >>=20 >> DNS Push Notification clients and servers MUST support DSO, but (as >> stated in the DSO specification [ >> DSO >> ]) the server SHOULD NOT issue >> any DSO messages until after the client has first initiated an >> acknowledged DSO message of its own. A single server can support DNS >> Queries, DNS Updates, and DNS Push Notifications (using DSO) on the >> same TCP port, and until the client has sent at least one DSO >> message, the server does not know what kind of client has connected >> to it. Once the client has indicated willingness to use DSO by >> sending one of its own, either side of the session may then initiate >> further DSO messages at any time. >>=20 >>=20 >> It's just reiterating what the DNS Stateful Operations document says, and= what was said previously about updates and so on. Less text better? >=20 > I agree. >=20 > Ok, that=E2=80=99s as far as I got tonight. More tomorrow. >=20 > Thanks! >=20 > Tom >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Oct 29 10:21:20 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22757131038 for ; Mon, 29 Oct 2018 10:21:18 -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 32xS3hABIs2x for ; Mon, 29 Oct 2018 10:21:15 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8979131023 for ; Mon, 29 Oct 2018 10:21:14 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gHBE0-0004fX-8Z for dnssd@ietf.org; Mon, 29 Oct 2018 18:21:13 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gHBDq-0005pX-U3 for dnssd@ietf.org; Mon, 29 Oct 2018 13:21:08 -0400 Received: (qmail 14842 invoked from network); 29 Oct 2018 17:20:59 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Oct 2018 17:20:59 -0000 To: Lanlan Pan Cc: dnssd References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb 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: <0f32e79a-447a-f308-4888-4037a41716dd@huitema.net> Date: Mon, 29 Oct 2018 10:20:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C426693994AA3714F6D694B9" Content-Language: en-US X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rm4BWBOK7o3nnEkYLYU6hd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxWU3OM5er+4OpHk4e537NbVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5NAmFR3BiNNySzE1qhn3ItE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsexk4wJWtdaqW2wvzQnHqHofPwUimsNGvJJilSn4u6QSZMYxY+yfwQdi 60gXjcORueAs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GALxCCXdUXmVhCtBec/fcEYvj esdofIZr77ejLGfC2JB7N1zg8T9ahw4hquQDupK1jk8cW9l7L/bUyy3TdA61l2cpmNv6myoo0El0 HMr4saZ1zojKkehi/vTYmvdG6r3KiNIivy+nwsaRXVdompsKqyK6MiFNXPsSc8iR2XN+gTM3647l NwN4qOsSZg+fYhVZGz9r7Mz0gFF1wxz5bb0bhP2vPRlp44C0jVYGRiPSt4ToCZPO2GKNZaMtjfyA obtcMvAFMvX7q8M4x6bP/gjzw0OjTdGcfvx5IojyUdakbY3OIKvEx19waJj/yR/yCVBWvmU/ts+C IC6rClmkQnuoxlv2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [dnssd] Next steps for privacy discovery 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, 29 Oct 2018 17:21:18 -0000 This is a multi-part message in MIME format. --------------C426693994AA3714F6D694B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/28/2018 6:48 PM, Lanlan Pan wrote: > > > Christian Huitema >=E4=BA=8E2018=E5=B9=B410=E6=9C=8826=E6=97=A5= =E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=883:09=E5=86=99=E9=81=93=EF=BC=9A > > ... > > 4) If we kept the current "two phase" structure, use a TLS protocol= > extension to demonstrate knowledge of the server's public key in th= e > client hello. I think we can build on the work done for SNI > encryption, > which would fit quite well. > > > I wonder if we could consider about use tls psk (pre-shared key) ?=C2=A0= > server can assign different key to different client. That's what we were specifying in the current privacy draft. There are two issues. The first one is that if you use TLS-PSK, the Client Hello must include a key identifier. If there is a different key for each client, the key identifier could become a client identifier. We solved that=C2=A0 by using a "predictable nonce" for key identifier. The second issue is of course that assigning different keys to different clients requires extra management at the server, something that is not needed in the "private public key" class of solutions. -- Christian Huitema --------------C426693994AA3714F6D694B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/28/2018 6:48 PM, Lanlan Pan wrote:


Christian Huitema <huitema@huitema.net>于2018年10月26日周五 下午3:09写道：
...

4) If we kept the current "two phase" structure, use a TLS protocol
extension to demonstrate knowledge of the server's public key in the
client hello. I think we can build on the work done for SNI encryption,
which would fit quite well.

I wonder if we could consider about use tls psk (pre-shared key) ?  server can assign different key to different client.

That's what we were specifying in the current privacy draft. There are two issues. The first one is that if you use TLS-PSK, the Client Hello must include a key identifier. If there is a different key for each client, the key identifier could become a client identifier. We solved that  by using a "predictable nonce" for key identifier. The second issue is of course that assigning different keys to different clients requires extra management at the server, something that is not needed in the "private public key" class of solutions.

-- Christian Huitema
--------------C426693994AA3714F6D694B9-- From nobody Mon Oct 29 13:45:26 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B65131069 for ; Mon, 29 Oct 2018 13:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h7hchmzh2Muh for ; Mon, 29 Oct 2018 13:45:21 -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 18585131025 for ; Mon, 29 Oct 2018 13:45:21 -0700 (PDT) Received: from butte.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (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 4A57121331; Mon, 29 Oct 2018 16:45:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: Date: Mon, 29 Oct 2018 16:45:19 -0400 Cc: "Jan Komissar (jkomissa)" , Stuart Cheshire , Tim Wicinski , dnssd , David Schinazi Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 29 Oct 2018 20:45:24 -0000 Continuing on=E2=80=A6 Comments inline. > On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: >=20 > Section 6.1 says: >=20 > The client begins by opening a DSO Session to its normal configured > DNS recursive resolver and requesting a Push Notification > subscription. If this is successful, then the recursive resolver > will make appropriate Push Notification subscriptions on the = client's > behalf, and the client will receive appropriate results. If the > recursive resolver does not support Push Notification = subscriptions, > then it will return an error code, and the client should proceed to > discover the appropriate server for direct communication. The = client > MUST also determine which TCP port on the server is listening for > connections, which need not be (and often is not) the typical TCP > port 53 used for conventional DNS, or TCP port 853 used for DNS = over=20 >=20 > TLS [RFC7858]. >=20 > This is inconsistent with the earlier assertion that the server we are = talking to is an authoritative server. How do we know what zone, if = any, the default resolver is authoritative for? What if it can support = some push notifications we want, but for others we need to talk to the = authoritative server? What about TLS? >=20 > I think this text was added based on a comment I made a while back; I = think that the behavior defined here may be okay, but there should be = some additional text: >=20 > The client begins by opening a DSO Session to its normal configured > DNS recursive resolver and requesting a Push Notification > subscription. This connection is made to the default DNS-over-TLS >=20 > port. If this connection is successful, then the recursive = resolver > will make appropriate Push Notification subscriptions on the = client's > behalf, and the client will receive appropriate results.=20 >=20 >=20 > In many contexts, the local recursive resolver will be able to = handle > push notifications for all zones that the client may need to = follow. > In other cases, the client may require Push Notifications from more > than one zone, and those zones may be served by different servers. > It is assumed here, therefore, that the client may need to maintain > connections to more than one DNS Push server.. >=20 > In some cases, > the recursive resolver may not be able to get answers for a = particular > zone. In this case, rather than returning SERVFAIL, the resolver > returns NOTAUTH. This signals the client that queries for this = zone > can't be handled by the local caching resolver. For that zone, = the > client SHOULD contact the zone's DNS Push server itself, even if > all other DNS Push queries can be handled by the local resolver. > This may be necessary in cases where the client is connected to a = VPN, > for example, or where the client has a pre-established trust = relationship > with the owner of the zone that allows the client, but not the = local > resolver, to successfully get answers for queries in that zone. >=20 > If the > recursive resolver does not support Push Notification = subscriptions, > then it will return an error code, DSONOTIMPL. This occurs when = the >=20 > local resolver follows the procedure below and does not find an SRV > record indicating support for DNS Push Notifications. >=20 > In case of either failure, the client should proceed to > discover the appropriate server for direct communication. The = client >=20 > MUST also determine which TCP port on the server is listening for > connections, which need not be (and often is not) the typical TCP > port 53 used for conventional DNS, or TCP port 853 used for DNS = over=20 >=20 > TLS [RFC7858]. Looks good. Adopted. >=20 > Later in 6.1: >=20 > 3. If the requested SOA record does not exist, the client will get > back a NOERROR/NODATA response or an NXDOMAIN/Name Error > response. In either case, the local resolver SHOULD include = the > SOA record for the zone of the requested name in the Authority > Section. >=20 >=20 > That SHOULD is updating RFC1035, I think, although I realize that = there's text later claiming it doesn't. How about "would normally"? = Given that we specify how clients handle the exceptional case, there's = no reason to get fussy about this here. BTW, we really ought to have a = document that describes this stuff, so that we can reference it. It's = a fairly common operation. changed to =E2=80=9Cwould normally=E2=80=9D. >=20 > At the bottom of Page 16 (the end of section 6.2.1) it might be good = to add some text acknowledging the recent deprecation of ANY queries, = and explicitly saying why they are not deprecated here. This avoids = the risk of DNSOP experts tripping on this, although they will probably = see the utility. This is the only thing I didn=E2=80=99t change yet. Looking at = https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07 doesn=E2=80=99t= exactly say it=E2=80=99s deprecated and our wording seems consistent = with the options given. I don=E2=80=99t understand how this could trip = up DNSOP experts. > The table in 6.2.2 is introduced by saying "Supported RCODEs are as = follows:" but then lists NXDOMAIN, for the purpose of explicitly = repeating that it is not supported. Subsequent text also refers to the = table as if all the RCODEs are permitted. This needs to be fixed. I = would take NXDOMAIN out of the table and just be really explicit about = how it's not allowed. 6.5.2 has the same issue, with the same cure. Fixed. >=20 > Also in 6.2.2: >=20 > For RCODE =3D 2 (SERVFAIL) the delay should be chosen according to the = level of server overload and the anticipated duration of that overload. = By default, a value of one minute is RECOMMENDED. If a more serious = server failure occurs, the delay may be longer in accordance with the = specific problem encountered. >=20 > In this case ideally there is more than one server, and the client can = try the next one in the list, rather than repeatedly connecting to the = same overloaded server. Or are we assuming the client will look the = server up again, and that round-robining will take care of this? Clarified. >=20 > Also in 6.2.2: >=20 > This is a misconfiguration, since this server is listed in a > "_dns-push-tls._tcp." SRV record, but the server itself is > not currently configured to support DNS Push Notifications for > that zone. Since it is possible that the misconfiguration may = be > repaired at any time, the retry delay should not be set too = high. > By default, a value of 5 minutes is RECOMMENDED. >=20 >=20 > Probably ought to say this: >=20 > If the server being queried is not the local resolver, rhis is a > misconfiguration, since this server is listed in a > "_dns-push-tls._tcp." SRV record, but the server itself is > not currently configured to support DNS Push Notifications for > that zone. Since it is possible that the misconfiguration may = be > repaired at any time, the retry delay should not be set too = high. > By default, a value of 5 minutes is RECOMMENDED. >=20 Adopted. >=20 > At the end of 6.3.1: >=20 > The TTL of an added record is stored by the client and decremented = as > time passes, with the caveat that for as long as a relevant > subscription is active, the TTL does not decrement below 1 second. > For as long as a relevant subscription remains active, the client > SHOULD assume that when a record goes away the server will notify = it > of that fact. Consequently, a client does not have to poll to = verify > that the record is still there. Once a subscription is cancelled > (individually, or as a result of the DSO session being closed) = record > aging resumes and records are removed from the local cache when = their=20 >=20 > TTL reaches zero. >=20 > There's a slight problem with this: if the caching resolver is doing = these queries on behalf of a client, then it shouldn't be decrementing = the TTL. Also, if we haven't received an update from the server saying = that the TTL has a new value, then the TTL doesn't have a new = value=E2=80=94it's still whatever the server sent last time. So it = would actually be correct to never decrement the TTL while a = subscription is active. So I would suggest: >=20 > The TTL of an added record is stored by the client. While the = subscription > is active, the TTL is not decremented, because a change to the TTL = would > produce a new update. > For as long as a relevant subscription remains active, the client > SHOULD assume that when a record goes away the server will notify = it > of that fact. Consequently, a client does not have to poll to = verify > that the record is still there. Once a subscription is cancelled > (individually, or as a result of the DSO session being closed) = record > aging for records covered by the subscription resumes and records = are >=20 > removed from the local cache when their=20 > TTL reaches zero. Sounds good. >=20 > Section 7.4 talks about TLS session resumption and that subscriptions = have to be reinstantiated, but implies without stating explicitly that = closing a TLS session closes the DSO session. It might be worth saying = that explicitly. Something like: >=20 > TLS Session Resumption is permissible on DNS Push Notification > servers. The server may keep TLS state with Session IDs [RFC5246 > ] or > operate in stateless mode by sending a Session Ticket [ > RFC5077 > ] to > the client for it to store. However, closing the TLS connection >=20 > terminates the the DSO session. When the TLS session is > resumed, the DNS Push Notification server will not have any > subscription state and will proceed as with any other new DSO > session. Use of TLS Session Resumption allows a new TLS connection > to be set up more quickly, but the client will still have to = recreate > any desired subscriptions. >=20 Done. >=20 > In section 8, you probably ought to use two tables rather than one. = Also, I don't think you've given enough information for the service name = registration. Split the table and added a =E2=80=9Cnone" port for clarity. Thanks again! Tom From nobody Mon Oct 29 13:55:34 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1B8130FC2 for ; Mon, 29 Oct 2018 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.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 OBQIMXKCB-wF for ; Mon, 29 Oct 2018 13:55:29 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 CC20613108C for ; Mon, 29 Oct 2018 13:55:28 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id b22-v6so10991470qtr.11 for ; Mon, 29 Oct 2018 13:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nM/0JU3MModDEYT/x4OfcXQ1V7rZfnrqb2I7YjroOQs=; b=DtYe+cjoNwDe518K+60YA13LLc9s+G3DyBJLfucGaP/Tyvx3O/eg28dn6fFcR6m4Jp dQHTbKN+r6Wk2wePSI2dTPLY/3ZgcTIYXDdtM19fHq1fsaDjjuF+xdhSBlDpangnh11V 6Mk/erwLUaZtYV0ChHUXba5Xqmy/z+rj09ID59Rr7pUFz6DpQH5YhrYkDyk9EUkeZadZ pWHao93TbUtymeeiTX+Q3g5FblSzwqbE07qDbOviezputoq4izOcNyEa+im+Uu100hB5 ENvCWjnyKjmbQ2y+SBe/YtBWGz70473kZ6B3uzAil2WYQOUmdCMRHIX4OmOg2kgANDcd eYoQ== 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=nM/0JU3MModDEYT/x4OfcXQ1V7rZfnrqb2I7YjroOQs=; b=spQnYKIrJxso8Ik0lKDe06xHiDw+7GHglf3zUbJubr7iYv6WOjsfQ04h5tb8BbZ2yh 2IIoFM4Z+9Z7FvrH34M2TEobEBIx1c3q2mPRvEWnBEJ3/dWK/V8fIBt0xXLS1kAkavt5 qaIfsMSBkES9B7D+TiGsLx7Gqu8iMRPENP6ppeGlPp/5pYroueKfYVtn2it/+EY3Tn4W ItzP4+Ie+KsAJYNdwQNQCjdMeHAYVM+9Hd1wLv3q9c7dbqBFbcm00QPea+w2Odx22LB3 X1UMK75X5UTHh3JZBogeUotpl9pTcA337IRXFGLzDEJ3OUlD8S5fj+W8bAm45g4BgTWN 5rJA== X-Gm-Message-State: AGRZ1gK/ugtJod0VFeI9Xmxeth2sjDLgRUqOmPULZg2b4tzkUuyQsKY+ pCLXStqctzvOvqNV8Iidw1wNlIXMa9YKy2pdHW/BeQ== X-Google-Smtp-Source: AJdET5fFmo0ln2fZzDLaH/au7CY7G3BDkGRqMvDGzVDylcH1SYpN/GiaxeOfY+XZHYDsmir++cwfTfNWwiQNWtO4ZKQ= X-Received: by 2002:a0c:c966:: with SMTP id v35mr14690139qvj.45.1540846527784; Mon, 29 Oct 2018 13:55:27 -0700 (PDT) MIME-Version: 1.0 References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> In-Reply-To: From: Ted Lemon Date: Mon, 29 Oct 2018 16:54:51 -0400 Message-ID: To: Tom Pusateri Cc: "Jan Komissar (jkomissa)" , Stuart Cheshire , Tim Wicinski , dnssd , David Schinazi Content-Type: multipart/alternative; boundary="000000000000f13cdc0579644944" Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 29 Oct 2018 20:55:33 -0000 --000000000000f13cdc0579644944 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome, thanks! :) I think it's fine if we just wait to see what DNSOP says about ANY. On Mon, Oct 29, 2018 at 4:45 PM Tom Pusateri wrote: > Continuing on=E2=80=A6 Comments inline. > > > On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: > > > > Section 6.1 says: > > > > The client begins by opening a DSO Session to its normal configured > > DNS recursive resolver and requesting a Push Notification > > subscription. If this is successful, then the recursive resolver > > will make appropriate Push Notification subscriptions on the client'= s > > behalf, and the client will receive appropriate results. If the > > recursive resolver does not support Push Notification subscriptions, > > then it will return an error code, and the client should proceed to > > discover the appropriate server for direct communication. The clien= t > > MUST also determine which TCP port on the server is listening for > > connections, which need not be (and often is not) the typical TCP > > port 53 used for conventional DNS, or TCP port 853 used for DNS over > > > > TLS [RFC7858]. > > > > This is inconsistent with the earlier assertion that the server we are > talking to is an authoritative server. How do we know what zone, if any= , > the default resolver is authoritative for? What if it can support some > push notifications we want, but for others we need to talk to the > authoritative server? What about TLS? > > > > I think this text was added based on a comment I made a while back; I > think that the behavior defined here may be okay, but there should be som= e > additional text: > > > > The client begins by opening a DSO Session to its normal configured > > DNS recursive resolver and requesting a Push Notification > > subscription. This connection is made to the default DNS-over-TLS > > > > port. If this connection is successful, then the recursive resolve= r > > will make appropriate Push Notification subscriptions on the client'= s > > behalf, and the client will receive appropriate results. > > > > > > In many contexts, the local recursive resolver will be able to handl= e > > push notifications for all zones that the client may need to follow. > > In other cases, the client may require Push Notifications from more > > than one zone, and those zones may be served by different servers. > > It is assumed here, therefore, that the client may need to maintain > > connections to more than one DNS Push server.. > > > > In some cases, > > the recursive resolver may not be able to get answers for a particul= ar > > zone. In this case, rather than returning SERVFAIL, the resolver > > returns NOTAUTH. This signals the client that queries for this zon= e > > can't be handled by the local caching resolver. For that zone, the > > client SHOULD contact the zone's DNS Push server itself, even if > > all other DNS Push queries can be handled by the local resolver. > > This may be necessary in cases where the client is connected to a VP= N, > > for example, or where the client has a pre-established trust > relationship > > with the owner of the zone that allows the client, but not the local > > resolver, to successfully get answers for queries in that zone. > > > > If the > > recursive resolver does not support Push Notification subscriptions, > > then it will return an error code, DSONOTIMPL. This occurs when th= e > > > > local resolver follows the procedure below and does not find an SRV > > record indicating support for DNS Push Notifications. > > > > In case of either failure, the client should proceed to > > discover the appropriate server for direct communication. The clien= t > > > > MUST also determine which TCP port on the server is listening for > > connections, which need not be (and often is not) the typical TCP > > port 53 used for conventional DNS, or TCP port 853 used for DNS over > > > > TLS [RFC7858]. > > Looks good. Adopted. > > > > > Later in 6.1: > > > > 3. If the requested SOA record does not exist, the client will get > > back a NOERROR/NODATA response or an NXDOMAIN/Name Error > > response. In either case, the local resolver SHOULD include the > > SOA record for the zone of the requested name in the Authority > > Section. > > > > > > That SHOULD is updating RFC1035, I think, although I realize that > there's text later claiming it doesn't. How about "would normally"? > Given that we specify how clients handle the exceptional case, there's n= o > reason to get fussy about this here. BTW, we really ought to have a > document that describes this stuff, so that we can reference it. It's a > fairly common operation. > > changed to =E2=80=9Cwould normally=E2=80=9D. > > > > > At the bottom of Page 16 (the end of section 6.2.1) it might be good to > add some text acknowledging the recent deprecation of ANY queries, and > explicitly saying why they are not deprecated here. This avoids the ris= k > of DNSOP experts tripping on this, although they will probably see the > utility. > > This is the only thing I didn=E2=80=99t change yet. Looking at > https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07 doesn=E2=80=99= t > exactly say it=E2=80=99s deprecated and our wording seems consistent with= the > options given. I don=E2=80=99t understand how this could trip up DNSOP ex= perts. > > > The table in 6.2.2 is introduced by saying "Supported RCODEs are as > follows:" but then lists NXDOMAIN, for the purpose of explicitly repeatin= g > that it is not supported. Subsequent text also refers to the table as i= f > all the RCODEs are permitted. This needs to be fixed. I would take > NXDOMAIN out of the table and just be really explicit about how it's not > allowed. 6.5.2 has the same issue, with the same cure. > > Fixed. > > > > > Also in 6.2.2: > > > > For RCODE =3D 2 (SERVFAIL) the delay should be chosen according to the > level of server overload and the anticipated duration of that overload. B= y > default, a value of one minute is RECOMMENDED. If a more serious server > failure occurs, the delay may be longer in accordance with the specific > problem encountered. > > > > In this case ideally there is more than one server, and the client can > try the next one in the list, rather than repeatedly connecting to the sa= me > overloaded server. Or are we assuming the client will look the server u= p > again, and that round-robining will take care of this? > > Clarified. > > > > > Also in 6.2.2: > > > > This is a misconfiguration, since this server is listed in a > > "_dns-push-tls._tcp." SRV record, but the server itself is > > not currently configured to support DNS Push Notifications for > > that zone. Since it is possible that the misconfiguration may be > > repaired at any time, the retry delay should not be set too high. > > By default, a value of 5 minutes is RECOMMENDED. > > > > > > Probably ought to say this: > > > > If the server being queried is not the local resolver, rhis is a > > misconfiguration, since this server is listed in a > > "_dns-push-tls._tcp." SRV record, but the server itself is > > not currently configured to support DNS Push Notifications for > > that zone. Since it is possible that the misconfiguration may be > > repaired at any time, the retry delay should not be set too high. > > By default, a value of 5 minutes is RECOMMENDED. > > > > Adopted. > > > > > At the end of 6.3.1: > > > > The TTL of an added record is stored by the client and decremented a= s > > time passes, with the caveat that for as long as a relevant > > subscription is active, the TTL does not decrement below 1 second. > > For as long as a relevant subscription remains active, the client > > SHOULD assume that when a record goes away the server will notify it > > of that fact. Consequently, a client does not have to poll to verif= y > > that the record is still there. Once a subscription is cancelled > > (individually, or as a result of the DSO session being closed) recor= d > > aging resumes and records are removed from the local cache when thei= r > > > > TTL reaches zero. > > > > There's a slight problem with this: if the caching resolver is doing > these queries on behalf of a client, then it shouldn't be decrementing th= e > TTL. Also, if we haven't received an update from the server saying that > the TTL has a new value, then the TTL doesn't have a new value=E2=80=94it= 's still > whatever the server sent last time. So it would actually be correct to > never decrement the TTL while a subscription is active. So I would > suggest: > > > > The TTL of an added record is stored by the client. While the > subscription > > is active, the TTL is not decremented, because a change to the TTL > would > > produce a new update. > > For as long as a relevant subscription remains active, the client > > SHOULD assume that when a record goes away the server will notify it > > of that fact. Consequently, a client does not have to poll to verif= y > > that the record is still there. Once a subscription is cancelled > > (individually, or as a result of the DSO session being closed) recor= d > > aging for records covered by the subscription resumes and records ar= e > > > > removed from the local cache when their > > TTL reaches zero. > > Sounds good. > > > > > Section 7.4 talks about TLS session resumption and that subscriptions > have to be reinstantiated, but implies without stating explicitly that > closing a TLS session closes the DSO session. It might be worth saying > that explicitly. Something like: > > > > TLS Session Resumption is permissible on DNS Push Notification > > servers. The server may keep TLS state with Session IDs [RFC5246 > > ] or > > operate in stateless mode by sending a Session Ticket [ > > RFC5077 > > ] to > > the client for it to store. However, closing the TLS connection > > > > terminates the the DSO session. When the TLS session is > > resumed, the DNS Push Notification server will not have any > > subscription state and will proceed as with any other new DSO > > session. Use of TLS Session Resumption allows a new TLS connection > > to be set up more quickly, but the client will still have to recreat= e > > any desired subscriptions. > > > > Done. > > > > > In section 8, you probably ought to use two tables rather than one. > Also, I don't think you've given enough information for the service name > registration. > > > Split the table and added a =E2=80=9Cnone" port for clarity. > > Thanks again! > > Tom > > --000000000000f13cdc0579644944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Awesome, thanks! :)

I think it'= s fine if we just wait to see what DNSOP says about ANY.

On Mon, Oct 29, 2018 at 4:45 PM To= m Pusateri <pusateri@bangj.com= > wrote:
Continuing on=E2=80=A6 = Comments inline.

> On Oct 26, 2018, at 5:28 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> Section 6.1 says:
>
>=C2=A0 =C2=A0 The client begins by opening a DSO Session to its normal = configured
>=C2=A0 =C2=A0 DNS recursive resolver and requesting a Push Notification=
>=C2=A0 =C2=A0 subscription.=C2=A0 If this is successful, then the recur= sive resolver
>=C2=A0 =C2=A0 will make appropriate Push Notification subscriptions on = the client's
>=C2=A0 =C2=A0 behalf, and the client will receive appropriate results.= =C2=A0 If the
>=C2=A0 =C2=A0 recursive resolver does not support Push Notification sub= scriptions,
>=C2=A0 =C2=A0 then it will return an error code, and the client should = proceed to
>=C2=A0 =C2=A0 discover the appropriate server for direct communication.= =C2=A0 The client
>=C2=A0 =C2=A0 MUST also determine which TCP port on the server is liste= ning for
>=C2=A0 =C2=A0 connections, which need not be (and often is not) the typ= ical TCP
>=C2=A0 =C2=A0 port 53 used for conventional DNS, or TCP port 853 used f= or DNS over
>
>=C2=A0 =C2=A0 TLS [RFC7858].
>
> This is inconsistent with the earlier assertion that the server we are= talking to is an authoritative server.=C2=A0 =C2=A0How do we know what zon= e, if any, the default resolver is authoritative for?=C2=A0 =C2=A0What if i= t can support some push notifications we want, but for others we need to ta= lk to the authoritative server?=C2=A0 =C2=A0What about TLS?
>
> I think this text was added based on a comment I made a while back; I = think that the behavior defined here may be okay, but there should be some = additional text:
>
>=C2=A0 =C2=A0 The client begins by opening a DSO Session to its normal = configured
>=C2=A0 =C2=A0 DNS recursive resolver and requesting a Push Notification=
>=C2=A0 =C2=A0 subscription.=C2=A0 This connection is made to the defaul= t DNS-over-TLS
>
>=C2=A0 =C2=A0 port.=C2=A0 =C2=A0If this connection is successful, then = the recursive resolver
>=C2=A0 =C2=A0 will make appropriate Push Notification subscriptions on = the client's
>=C2=A0 =C2=A0 behalf, and the client will receive appropriate results. =
>
>
>=C2=A0 =C2=A0 In many contexts, the local recursive resolver will be ab= le to handle
>=C2=A0 =C2=A0 push notifications for all zones that the client may need= to follow.
>=C2=A0 =C2=A0 In other cases, the client may require Push Notifications= from more
>=C2=A0 =C2=A0 than one zone, and those zones may be served by different= servers.
>=C2=A0 =C2=A0 It is assumed here, therefore, that the client may need t= o maintain
>=C2=A0 =C2=A0 connections to more than one DNS Push server..
>
>=C2=A0 =C2=A0 In some cases,
>=C2=A0 =C2=A0 the recursive resolver may not be able to get answers for= a particular
>=C2=A0 =C2=A0 zone.=C2=A0 =C2=A0In this case, rather than returning SER= VFAIL, the resolver
>=C2=A0 =C2=A0 returns NOTAUTH.=C2=A0 =C2=A0This signals the client that= queries for this zone
>=C2=A0 =C2=A0 can't be handled by the local caching resolver.=C2=A0= =C2=A0For that zone, the
>=C2=A0 =C2=A0 client SHOULD contact the zone's DNS Push server itse= lf, even if
>=C2=A0 =C2=A0 all other DNS Push queries can be handled by the local re= solver.
>=C2=A0 =C2=A0 This may be necessary in cases where the client is connec= ted to a VPN,
>=C2=A0 =C2=A0 for example, or where the client has a pre-established tr= ust relationship
>=C2=A0 =C2=A0 with the owner of the zone that allows the client, but no= t the local
>=C2=A0 =C2=A0 resolver, to successfully get answers for queries in that= zone.
>
>=C2=A0 =C2=A0 If the
>=C2=A0 =C2=A0 recursive resolver does not support Push Notification sub= scriptions,
>=C2=A0 =C2=A0 then it will return an error code, DSONOTIMPL.=C2=A0 =C2= =A0This occurs when the
>
>=C2=A0 =C2=A0 local resolver follows the procedure below and does not f= ind an SRV
>=C2=A0 =C2=A0 record indicating support for DNS Push Notifications.
>
>=C2=A0 =C2=A0 In case of either failure, the client should proceed to >=C2=A0 =C2=A0 discover the appropriate server for direct communication.= =C2=A0 The client
>
>=C2=A0 =C2=A0 MUST also determine which TCP port on the server is liste= ning for
>=C2=A0 =C2=A0 connections, which need not be (and often is not) the typ= ical TCP
>=C2=A0 =C2=A0 port 53 used for conventional DNS, or TCP port 853 used f= or DNS over
>
>=C2=A0 =C2=A0 TLS [RFC7858].

Looks good. Adopted.

>
> Later in 6.1:
>
>=C2=A0 =C2=A0 3.=C2=A0 If the requested SOA record does not exist, the = client will get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 back a NOERROR/NODATA response or an NXDOMA= IN/Name Error
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 response.=C2=A0 In either case, the local r= esolver SHOULD include the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SOA record for the zone of the requested na= me in the Authority
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section.
>
>
> That SHOULD is updating RFC1035, I think, although I realize that ther= e's text later claiming it doesn't.=C2=A0 =C2=A0How about "wou= ld normally"?=C2=A0 =C2=A0Given that we specify how clients handle the= exceptional case, there's no reason to get fussy about this here.=C2= =A0 =C2=A0BTW, we really ought to have a document that describes this stuff= , so that we can reference it.=C2=A0 =C2=A0It's a fairly common operati= on.

changed to =E2=80=9Cwould normally=E2=80=9D.

>
> At the bottom of Page 16 (the end of section 6.2.1) it might be good t= o add some text acknowledging the recent deprecation of ANY queries, and ex= plicitly saying why they are not deprecated here.=C2=A0 =C2=A0This avoids t= he risk of DNSOP experts tripping on this, although they will probably see = the utility.

This is the only thing I didn=E2=80=99t change yet. Looking at https://tools.ietf.org/html/draft-ietf-dnsop-refuse-an= y-07 doesn=E2=80=99t exactly say it=E2=80=99s deprecated and our wordin= g seems consistent with the options given. I don=E2=80=99t understand how t= his could trip up DNSOP experts.

> The table in 6.2.2 is introduced by saying "Supported RCODEs are = as follows:" but then lists NXDOMAIN, for the purpose of explicitly re= peating that it is not supported.=C2=A0 =C2=A0Subsequent text also refers t= o the table as if all the RCODEs are permitted.=C2=A0 =C2=A0This needs to b= e fixed.=C2=A0 =C2=A0I would take NXDOMAIN out of the table and just be rea= lly explicit about how it's not allowed.=C2=A0 =C2=A06.5.2 has the same= issue, with the same cure.

Fixed.

>
> Also in 6.2.2:
>
> For RCODE =3D 2 (SERVFAIL) the delay should be chosen according to the= level of server overload and the anticipated duration of that overload. By= default, a value of one minute is RECOMMENDED. If a more serious server fa= ilure occurs, the delay may be longer in accordance with the specific probl= em encountered.
>
> In this case ideally there is more than one server, and the client can= try the next one in the list, rather than repeatedly connecting to the sam= e overloaded server.=C2=A0 =C2=A0Or are we assuming the client will look th= e server up again, and that round-robining will take care of this?

Clarified.

>
> Also in 6.2.2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is a misconfiguration, since this serve= r is listed in a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"_dns-push-tls._tcp.<zone>" = SRV record, but the server itself is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not currently configured to support DNS Push= Notifications for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that zone.=C2=A0 Since it is possible that t= he misconfiguration may be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired at any time, the retry delay should= not be set too high.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0By default, a value of 5 minutes is RECOMMEN= DED.
>
>
> Probably ought to say this:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the server being queried is not the local= resolver, rhis is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0misconfiguration, since this server is liste= d in a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"_dns-push-tls._tcp.<zone>" = SRV record, but the server itself is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not currently configured to support DNS Push= Notifications for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that zone.=C2=A0 Since it is possible that t= he misconfiguration may be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired at any time, the retry delay should= not be set too high.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0By default, a value of 5 minutes is RECOMMEN= DED.
>

Adopted.

>
> At the end of 6.3.1:
>
>=C2=A0 =C2=A0 The TTL of an added record is stored by the client and de= cremented as
>=C2=A0 =C2=A0 time passes, with the caveat that for as long as a releva= nt
>=C2=A0 =C2=A0 subscription is active, the TTL does not decrement below = 1 second.
>=C2=A0 =C2=A0 For as long as a relevant subscription remains active, th= e client
>=C2=A0 =C2=A0 SHOULD assume that when a record goes away the server wil= l notify it
>=C2=A0 =C2=A0 of that fact.=C2=A0 Consequently, a client does not have = to poll to verify
>=C2=A0 =C2=A0 that the record is still there.=C2=A0 Once a subscription= is cancelled
>=C2=A0 =C2=A0 (individually, or as a result of the DSO session being cl= osed) record
>=C2=A0 =C2=A0 aging resumes and records are removed from the local cach= e when their
>
>=C2=A0 =C2=A0 TTL reaches zero.
>
> There's a slight problem with this: if the caching resolver is doi= ng these queries on behalf of a client, then it shouldn't be decrementi= ng the TTL.=C2=A0 =C2=A0Also, if we haven't received an update from the= server saying that the TTL has a new value, then the TTL doesn't have = a new value=E2=80=94it's still whatever the server sent last time.=C2= =A0 =C2=A0So it would actually be correct to never decrement the TTL while = a subscription is active.=C2=A0 =C2=A0So I would suggest:
>
>=C2=A0 =C2=A0 The TTL of an added record is stored by the client.=C2=A0= =C2=A0While the subscription
>=C2=A0 =C2=A0 is active, the TTL is not decremented, because a change t= o the TTL would
>=C2=A0 =C2=A0 produce a new update.
>=C2=A0 =C2=A0 For as long as a relevant subscription remains active, th= e client
>=C2=A0 =C2=A0 SHOULD assume that when a record goes away the server wil= l notify it
>=C2=A0 =C2=A0 of that fact.=C2=A0 Consequently, a client does not have = to poll to verify
>=C2=A0 =C2=A0 that the record is still there.=C2=A0 Once a subscription= is cancelled
>=C2=A0 =C2=A0 (individually, or as a result of the DSO session being cl= osed) record
>=C2=A0 =C2=A0 aging for records covered by the subscription resumes and= records are
>
>=C2=A0 =C2=A0 removed from the local cache when their
>=C2=A0 =C2=A0 TTL reaches zero.

Sounds good.

>
> Section 7.4 talks about TLS session resumption and that subscriptions = have to be reinstantiated, but implies without stating explicitly that clos= ing a TLS session closes the DSO session.=C2=A0 =C2=A0It might be worth say= ing that explicitly.=C2=A0 =C2=A0Something like:
>
>=C2=A0 =C2=A0 TLS Session Resumption is permissible on DNS Push Notific= ation
>=C2=A0 =C2=A0 servers.=C2=A0 The server may keep TLS state with Session= IDs [RFC5246
> ] or
>=C2=A0 =C2=A0 operate in stateless mode by sending a Session Ticket [ > RFC5077
> ] to
>=C2=A0 =C2=A0 the client for it to store.=C2=A0 However, closing the TL= S connection
>
>=C2=A0 =C2=A0 terminates the=C2=A0 the DSO session.=C2=A0 When the TLS = session is
>=C2=A0 =C2=A0 resumed, the DNS Push Notification server will not have a= ny
>=C2=A0 =C2=A0 subscription state and will proceed as with any other new= DSO
>=C2=A0 =C2=A0 session.=C2=A0 Use of TLS Session Resumption allows a new= TLS connection
>=C2=A0 =C2=A0 to be set up more quickly, but the client will still have= to recreate
>=C2=A0 =C2=A0 any desired subscriptions.
>

Done.

>
> In section 8, you probably ought to use two tables rather than one.=C2= =A0 =C2=A0Also, I don't think you've given enough information for t= he service name registration.


Split the table and added a =E2=80=9Cnone" port for clarity.

Thanks again!

Tom

--000000000000f13cdc0579644944-- From nobody Mon Oct 29 17:50:16 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA212426A for ; Mon, 29 Oct 2018 17:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2wUFwP76cdc for ; Mon, 29 Oct 2018 17:50:12 -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 1C58813102A for ; Mon, 29 Oct 2018 17:50:12 -0700 (PDT) Received: from butte.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (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 33BCA2137F; Mon, 29 Oct 2018 20:50:11 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: <3789E1FD-01A8-4356-A185-9AD1155C7F39@bangj.com> Date: Mon, 29 Oct 2018 20:50:10 -0400 Cc: Stuart Cheshire , Tim Wicinski , dnssd , Ted Lemon , David Schinazi Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> <3789E1FD-01A8-4356-A185-9AD1155C7F39@bangj.com> To: "Jan Komissar (jkomissa)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 30 Oct 2018 00:50:15 -0000 Ok this has been added. I will publish a new version as soon as = submissions open up again. 6.6. DNS Stateful Operations TLV Context Summary This document defines four new DSO TLVs. As suggested in [DSO], Section 8.2, the valid contexts of these new TLV types are summarized below. The client TLV contexts are: C-P: Client primary bidirectional TLV C-U: Client primary unidirectional TLV C-A: Client additional TLV CRP: Client response primary TLV CRA: Client response additional TLV +-------------+-----+-----+-----+-----+-----+ | Type | C-P | C-U | C-A | CRP | CRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | X | | | | | | PUSH | | | | | | | UNSUBSCRIBE | X | | | | | | RECONFIRM | X | | | | | +-------------+-----+-----+-----+-----+-----+ Table 3: DSO TLV Client Context Summary The server TLV contexts are: S-P: Server primary bidirectional TLV S-U: Server primary unidirectional TLV S-A: Server additional TLV SRP: Server response primary TLV SRA: Server response additional TLV +-------------+-----+-----+-----+-----+-----+ | Type | S-P | S-U | S-A | SRP | SRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | | | | | | | PUSH | | X | | | | | UNSUBSCRIBE | | | | | | | RECONFIRM | | | | | | +-------------+-----+-----+-----+-----+-----+ Table 4: DSO TLV Server Context Summary > On Oct 29, 2018, at 10:42 AM, Tom Pusateri wrote: >=20 > Yes, be glad to add this.=20 >=20 > Thanks! >=20 > Tom >=20 >> On Oct 29, 2018, at 10:34 AM, Jan Komissar (jkomissa) = wrote: >>=20 >> Hi Tom, >>=20 >> Another thing I noticed: In the DSO spec = (draft-ietf-dnsop-session-signal-16), in section 8.2 (p.51), there is a = table indicating proper usage of the various TLVs in the spec with a = recommendation to do the same for future TLV definitions. It might be = good to add that to the Push Notification spec as well. >>=20 >> Thanks, >>=20 >> Jan. >>=20 >> =EF=BB=BFOn 10/26/18, 9:15 PM, "Tom Pusateri" = wrote: >>=20 >>=20 >> Thanks for the feedback! Comments inline. >>=20 >>> On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: >>>=20 >>> I'm in favor of advancing the document. I have a few editorial = comments: >>>=20 >>> On Page 6: >>>=20 >>> For example, if a user presses the "Print" >>> button on their smartphone, and then leaves the phone showing the >>> printer discovery screen until the phone goes to sleep, then the >>> printer discovery screen should be automatically dismissed as the >>> device goes to sleep. If the user does still intend to print, this >>> will require them to press the "Print" button again when they wake >>> their phone up. >>>=20 >>>=20 >>> I don't think this is the right advice to give=E2=80=94it's not = necessary to dismiss the UI. It always surprises me when a context = switch results in something in the UI changing without me changing it. = The less surprising behavior would be to simply stop doing these = queries while the dialog isn't showing. The dialog isn't showing when = the phone is asleep. So maybe this text would accomplish the same = purpose without recommending a particular UI flow? >>>=20 >>> For example, if a user presses the "Print" button on their = smartphone, and then leaves the phone showing the printer discovery = screen until the phone goes to sleep, or switches >>> to a different app, then the push subscription should (SHOULD?) be = discontinued. When the phone wakes up, >>> or the user switches back to the application that is showing the = print >>> dialog, the subscription could be reinstated, perhaps after a brief = wait >>> to allow the user to dismiss the dialog if they no longer intend to = print. >>=20 >> I agree that too much implementation info here is not needed. How = about: >>=20 >> (a) A subscription should only be active when there is a valid = reason to need live data (for example, an on-screen display is currently = showing the results to the user) and the subscription SHOULD be = cancelled as soon as the need for that data ends (for example, when the = user dismisses that display). Implementations may want to implement idle = timeouts, so that if the user ceases interacting with the device, the = subscription is cancelled. >>=20 >>> Section 3 says: >>>=20 >>> Standard DNS Queries MAY be sent over a DNS Push Notification = connection, provided that these are queries for names falling within the = server's zone (the in the "_dns-push-tls._tcp." SRV = record). The RD (Recursion Desired) bit MUST be zero. If a query is = received with the RD bit set, matching records for names falling within = the server's zones should be returned with the RA (Recursion Available) = bit clear. If the query is for a name not in the server's zone, an error = with RCODE NOTAUTH (Not Authoritative) should be=20 >>> returned. >>>=20 >>> Why is this? What if this is a hybrid authoritative/caching = resolver? Also, later on we do actually specify that this can work = with the local resolver. ISTM you could say this instead and capture = what is necessary: >>>=20 >>> Standard DNS Queries MAY be sent over a DNS Push Notification >>> connection. For any zone for which the server is authoritative, = it >>>=20 >>> MUST respond authoritatively for queries on names falling within >>> that zone (e.g., the in the "_dns-push-tls._tcp." SRV >>> record) both for DNS Push Notification queries and for normal DNS >>>=20 >>> queries. For names for which the server is acting as a caching >>> resolver, e.g. when the server is the local resolver, for any query >>> for which it supports DNS Push Notifications, it MUST also support >>> standard queries. >>=20 >> That sounds better. I think the idea of subscriptions to a local = resolver came along later and this part didn=E2=80=99t get updated. >>=20 >>>=20 >>> Section 4 says: >>>=20 >>> In keeping with the more recent precedent, DNS Push Notification is >>> defined only for TCP. DNS Push Notification clients MUST use DNS >>> Stateful Operations (DSO) [ >>> DSO] running over TLS over TCP [RFC7858]. >>>=20 >>> But section 7 says: >>>=20 >>> The Strict Privacy Usage Profile for DNS over TLS is strongly >>> recommended for DNS Push Notifications as defined in "Usage = Profiles >>> for DNS over TLS and DNS over DTLS" [ >>> RFC8310]. >>>=20 >>> Which is it? :) >>=20 >> Ok, I intended to go strict only since it was a new protocol. Here = is the new text in Section 7: >>=20 >> The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for = DNS Push Notifications as defined in "Usage Profiles for DNS over TLS = and DNS over DTLS". Cleartext connections for DNS Push Notifications are = not permissible. Since this is a new protocol, transistion mechanisms = using the Opportunistic Privacy profile are deemed unnecessary. >>=20 >>>=20 >>> Section 5 says: >>>=20 >>> Token bucket rate limiting schemes are also effective >>> in providing fairness by a server across numerous client requests. >>>=20 >>>=20 >>> [Citation Needed] >>>=20 >>> Is there any reason to say this? >>=20 >> No. Probably better to remove it. >>=20 >>>=20 >>> DNS Push Notification clients and servers MUST support DSO, but (as >>> stated in the DSO specification [ >>> DSO >>> ]) the server SHOULD NOT issue >>> any DSO messages until after the client has first initiated an >>> acknowledged DSO message of its own. A single server can support = DNS >>> Queries, DNS Updates, and DNS Push Notifications (using DSO) on the >>> same TCP port, and until the client has sent at least one DSO >>> message, the server does not know what kind of client has connected >>> to it. Once the client has indicated willingness to use DSO by >>> sending one of its own, either side of the session may then = initiate >>> further DSO messages at any time. >>>=20 >>>=20 >>> It's just reiterating what the DNS Stateful Operations document = says, and what was said previously about updates and so on. Less text = better? >>=20 >> I agree. >>=20 >> Ok, that=E2=80=99s as far as I got tonight. More tomorrow. >>=20 >> Thanks! >>=20 >> Tom >>=20 >>=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 From nobody Mon Oct 29 19:13:31 2018 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294A126DBF for ; Mon, 29 Oct 2018 19:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8zNXsiJsxvc for ; Mon, 29 Oct 2018 19:13:25 -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 407C912008A for ; Mon, 29 Oct 2018 19:13:25 -0700 (PDT) Received: from butte.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (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 27C4A21395; Mon, 29 Oct 2018 22:13:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: Date: Mon, 29 Oct 2018 22:13:23 -0400 Cc: Stuart Cheshire , Tim Wicinski , dnssd , Ted Lemon Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <5AC9F8F4-F35C-4A7B-AAC2-105E25D60FBE@bangj.com> <3789E1FD-01A8-4356-A185-9AD1155C7F39@bangj.com> To: "Jan Komissar (jkomissa)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push 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, 30 Oct 2018 02:13:29 -0000 Here=E2=80=99s an updated version after Ted pointed out a copy and paste = error with Unsubscribe. Thanks Ted! Tom 6.6. DNS Stateful Operations TLV Context Summary This document defines four new DSO TLVs. As suggested in [DSO], Section 8.2, the valid contexts of these new TLV types are summarized below. The client TLV contexts are: C-P: Client primary TLV C-U: Client primary unidirectional TLV C-A: Client additional TLV CRP: Client response primary TLV CRA: Client response additional TLV +-------------+-----+-----+-----+-----+-----+ | TLV Type | C-P | C-U | C-A | CRP | CRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | X | | | | | | PUSH | | | | | | | UNSUBSCRIBE | | X | | | | | RECONFIRM | X | | | | | +-------------+-----+-----+-----+-----+-----+ Table 3: DSO TLV Client Context Summary The server TLV contexts are: S-P: Server primary TLV S-U: Server primary unidirectional TLV S-A: Server additional TLV SRP: Server response primary TLV SRA: Server response additional TLV +-------------+-----+-----+-----+-----+-----+ | TLV Type | S-P | S-U | S-A | SRP | SRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | | | | | | | PUSH | | X | | | | | UNSUBSCRIBE | | | | | | | RECONFIRM | | | | | | +-------------+-----+-----+-----+-----+-----+ Table 4: DSO TLV Server Context Summary > On Oct 29, 2018, at 8:50 PM, Tom Pusateri wrote: >=20 > Ok this has been added. I will publish a new version as soon as = submissions open up again. >=20 > 6.6. DNS Stateful Operations TLV Context Summary >=20 > This document defines four new DSO TLVs. As suggested in [DSO], > Section 8.2, the valid contexts of these new TLV types are = summarized > below. >=20 > The client TLV contexts are: >=20 > C-P: Client primary bidirectional TLV > C-U: Client primary unidirectional TLV > C-A: Client additional TLV > CRP: Client response primary TLV > CRA: Client response additional TLV >=20 > +-------------+-----+-----+-----+-----+-----+ > | Type | C-P | C-U | C-A | CRP | CRA | > +-------------+-----+-----+-----+-----+-----+ > | SUBSCRIBE | X | | | | | > | PUSH | | | | | | > | UNSUBSCRIBE | X | | | | | > | RECONFIRM | X | | | | | > +-------------+-----+-----+-----+-----+-----+ >=20 > Table 3: DSO TLV Client Context Summary >=20 > The server TLV contexts are: >=20 > S-P: Server primary bidirectional TLV > S-U: Server primary unidirectional TLV > S-A: Server additional TLV > SRP: Server response primary TLV > SRA: Server response additional TLV >=20 > +-------------+-----+-----+-----+-----+-----+ > | Type | S-P | S-U | S-A | SRP | SRA | > +-------------+-----+-----+-----+-----+-----+ > | SUBSCRIBE | | | | | | > | PUSH | | X | | | | > | UNSUBSCRIBE | | | | | | > | RECONFIRM | | | | | | > +-------------+-----+-----+-----+-----+-----+ >=20 > Table 4: DSO TLV Server Context Summary >=20 >=20 >=20 >> On Oct 29, 2018, at 10:42 AM, Tom Pusateri = wrote: >>=20 >> Yes, be glad to add this.=20 >>=20 >> Thanks! >>=20 >> Tom >>=20 >>> On Oct 29, 2018, at 10:34 AM, Jan Komissar (jkomissa) = wrote: >>>=20 >>> Hi Tom, >>>=20 >>> Another thing I noticed: In the DSO spec = (draft-ietf-dnsop-session-signal-16), in section 8.2 (p.51), there is a = table indicating proper usage of the various TLVs in the spec with a = recommendation to do the same for future TLV definitions. It might be = good to add that to the Push Notification spec as well. >>>=20 >>> Thanks, >>>=20 >>> Jan. >>>=20 >>> =EF=BB=BFOn 10/26/18, 9:15 PM, "Tom Pusateri" = wrote: >>>=20 >>>=20 >>> Thanks for the feedback! Comments inline. >>>=20 >>>> On Oct 26, 2018, at 5:28 PM, Ted Lemon wrote: >>>>=20 >>>> I'm in favor of advancing the document. I have a few editorial = comments: >>>>=20 >>>> On Page 6: >>>>=20 >>>> For example, if a user presses the "Print" >>>> button on their smartphone, and then leaves the phone showing the >>>> printer discovery screen until the phone goes to sleep, then the >>>> printer discovery screen should be automatically dismissed as the >>>> device goes to sleep. If the user does still intend to print, this >>>> will require them to press the "Print" button again when they wake >>>> their phone up. >>>>=20 >>>>=20 >>>> I don't think this is the right advice to give=E2=80=94it's not = necessary to dismiss the UI. It always surprises me when a context = switch results in something in the UI changing without me changing it. = The less surprising behavior would be to simply stop doing these = queries while the dialog isn't showing. The dialog isn't showing when = the phone is asleep. So maybe this text would accomplish the same = purpose without recommending a particular UI flow? >>>>=20 >>>> For example, if a user presses the "Print" button on their = smartphone, and then leaves the phone showing the printer discovery = screen until the phone goes to sleep, or switches >>>> to a different app, then the push subscription should (SHOULD?) be = discontinued. When the phone wakes up, >>>> or the user switches back to the application that is showing the = print >>>> dialog, the subscription could be reinstated, perhaps after a brief = wait >>>> to allow the user to dismiss the dialog if they no longer intend to = print. >>>=20 >>> I agree that too much implementation info here is not needed. How = about: >>>=20 >>> (a) A subscription should only be active when there is a valid = reason to need live data (for example, an on-screen display is currently = showing the results to the user) and the subscription SHOULD be = cancelled as soon as the need for that data ends (for example, when the = user dismisses that display). Implementations may want to implement idle = timeouts, so that if the user ceases interacting with the device, the = subscription is cancelled. >>>=20 >>>> Section 3 says: >>>>=20 >>>> Standard DNS Queries MAY be sent over a DNS Push Notification = connection, provided that these are queries for names falling within the = server's zone (the in the "_dns-push-tls._tcp." SRV = record). The RD (Recursion Desired) bit MUST be zero. If a query is = received with the RD bit set, matching records for names falling within = the server's zones should be returned with the RA (Recursion Available) = bit clear. If the query is for a name not in the server's zone, an error = with RCODE NOTAUTH (Not Authoritative) should be=20 >>>> returned. >>>>=20 >>>> Why is this? What if this is a hybrid authoritative/caching = resolver? Also, later on we do actually specify that this can work = with the local resolver. ISTM you could say this instead and capture = what is necessary: >>>>=20 >>>> Standard DNS Queries MAY be sent over a DNS Push Notification >>>> connection. For any zone for which the server is authoritative, = it >>>>=20 >>>> MUST respond authoritatively for queries on names falling within >>>> that zone (e.g., the in the "_dns-push-tls._tcp." SRV >>>> record) both for DNS Push Notification queries and for normal DNS >>>>=20 >>>> queries. For names for which the server is acting as a caching >>>> resolver, e.g. when the server is the local resolver, for any query >>>> for which it supports DNS Push Notifications, it MUST also support >>>> standard queries. >>>=20 >>> That sounds better. I think the idea of subscriptions to a local = resolver came along later and this part didn=E2=80=99t get updated. >>>=20 >>>>=20 >>>> Section 4 says: >>>>=20 >>>> In keeping with the more recent precedent, DNS Push Notification is >>>> defined only for TCP. DNS Push Notification clients MUST use DNS >>>> Stateful Operations (DSO) [ >>>> DSO] running over TLS over TCP [RFC7858]. >>>>=20 >>>> But section 7 says: >>>>=20 >>>> The Strict Privacy Usage Profile for DNS over TLS is strongly >>>> recommended for DNS Push Notifications as defined in "Usage = Profiles >>>> for DNS over TLS and DNS over DTLS" [ >>>> RFC8310]. >>>>=20 >>>> Which is it? :) >>>=20 >>> Ok, I intended to go strict only since it was a new protocol. Here = is the new text in Section 7: >>>=20 >>> The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for = DNS Push Notifications as defined in "Usage Profiles for DNS over TLS = and DNS over DTLS". Cleartext connections for DNS Push Notifications are = not permissible. Since this is a new protocol, transistion mechanisms = using the Opportunistic Privacy profile are deemed unnecessary. >>>=20 >>>>=20 >>>> Section 5 says: >>>>=20 >>>> Token bucket rate limiting schemes are also effective >>>> in providing fairness by a server across numerous client requests. >>>>=20 >>>>=20 >>>> [Citation Needed] >>>>=20 >>>> Is there any reason to say this? >>>=20 >>> No. Probably better to remove it. >>>=20 >>>>=20 >>>> DNS Push Notification clients and servers MUST support DSO, but (as >>>> stated in the DSO specification [ >>>> DSO >>>> ]) the server SHOULD NOT issue >>>> any DSO messages until after the client has first initiated an >>>> acknowledged DSO message of its own. A single server can support = DNS >>>> Queries, DNS Updates, and DNS Push Notifications (using DSO) on the >>>> same TCP port, and until the client has sent at least one DSO >>>> message, the server does not know what kind of client has connected >>>> to it. Once the client has indicated willingness to use DSO by >>>> sending one of its own, either side of the session may then = initiate >>>> further DSO messages at any time. >>>>=20 >>>>=20 >>>> It's just reiterating what the DNS Stateful Operations document = says, and what was said previously about updates and so on. Less text = better? >>>=20 >>> I agree. >>>=20 >>> Ok, that=E2=80=99s as far as I got tonight. More tomorrow. >>>=20 >>> Thanks! >>>=20 >>> Tom >>>=20 >>>=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 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd