From nobody Tue Jun 4 07:17:10 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D117912000E; Tue, 4 Jun 2019 07:17:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Trammell via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Trammell Message-ID: <155965782875.28092.15981061156595567480@ietfa.amsl.com> Date: Tue, 04 Jun 2019 07:17:08 -0700 Archived-At: Subject: [dnssd] Tsvart early review of draft-ietf-dnssd-push-19 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, 04 Jun 2019 14:17:09 -0000 Reviewer: Brian Trammell Review result: Ready with Nits This document appears to pose no transport concerns beyond those raised by the protocols on which it is substantially based, DoT [RFC7858] and DSO [RFC8490]. There are of course connectivity risks associated with using client-established server-push over TCP, but the design of DSO appears to adequately account for these. nit in 6.1: "default port for DNS-over-TLS DNS over TLS [RFC7858]" From nobody Fri Jun 7 06:26:11 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3F120140 for ; Fri, 7 Jun 2019 06:26:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 R6O81ykUydDK for ; Fri, 7 Jun 2019 06:26:07 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 E012A120223 for ; Fri, 7 Jun 2019 06:26:06 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id i125so1213966qkd.6 for ; Fri, 07 Jun 2019 06:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=V97flo8+SRA+aCG0PWOavQ02qtDuqTkYdNbpOPVm/y0=; b=zfXHexpy86reNHv0x+Z8YUmHl1M9AMggGMOldkUDSV6CTleRPIUFroCTGpZ35jIr5k 0+3eYOMhnGZ7CWO4cF+fgF/AE3GEhrv9RTdElLhawa/Mi3REbI+aDqUJy23uxev4Hyc3 Gz9+L70QIXbernTSgfD8OpSMoa8RfUlYn5QMCYVfB6bQHxxYrRbiH8BPK7UiVliTREGy Asc5sHHqaQ6OSs3z8z5kf576dbPL9u3mOjbSqspWu4Iy2c7oEyTFc7dF4a++o57ZHYyR QPAo5KbjdYXmRLORxOIyQb7SrmONp2s2cHo7s6zqtuYG3GlUKxa2bpmqa79SQqWakmcM DMrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=V97flo8+SRA+aCG0PWOavQ02qtDuqTkYdNbpOPVm/y0=; b=JLtZOqWJ8RpdUfH2+eN/PQz6igcGDorXrILzy06ueaP+JlUIxx07OFsGkNZWHoSWdy eFkW8AsgLjYEKMgPl9NHWKzJ6usQrNa0ewPmPpxXE7wPtVfrJzYZ38MCx4KS6R2uK2Em gUKQ2td+HmEMiMnll6EDEoeXbRmB8dNc9F+HPkVSrO4LZei/M/4Q9+TBtYQpY+jtKBgL By0poQs+6+Vf18EJq90VQ9n9loYkOlrVSSeHcwfE9P5JNiCfQB1WPq8pSo6OnRCGX2pG xO3wWQMqzwNyXu3oGi0MD//Rdp9LQzZ24oexhDYpWkUz5ybe1+25z3ZBEiDpl1ak88wu jUjg== X-Gm-Message-State: APjAAAUgwN8KSq6y4frw7eByo4aNWdGIIIkZvWbWpdsqPkm/cJH7ij4x WJ1lC9JLvmpaK2cTcQO2Jd+HOcnolUKYKQ== X-Google-Smtp-Source: APXvYqxh0eQZLB6qClMnvWPx49/ZBIzLii85TSyIHu4izGVp4R05qI5FbHl7qRqrbXy/qKS0ZzBGlg== X-Received: by 2002:a37:a854:: with SMTP id r81mr43683228qke.53.1559913965774; Fri, 07 Jun 2019 06:26:05 -0700 (PDT) Received: from [10.0.30.16] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v2sm976931qtf.24.2019.06.07.06.26.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 06:26:05 -0700 (PDT) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_F13F26AC-E883-4E87-B18B-5DAE6447DFD9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <76E9B94C-B722-4FD1-ADE8-21DCA6299065@fugue.com> Date: Fri, 7 Jun 2019 09:26:03 -0400 To: DNSSD X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dnssd] DNSSD at WWDC 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, 07 Jun 2019 13:26:09 -0000 --Apple-Mail=_F13F26AC-E883-4E87-B18B-5DAE6447DFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since we=E2=80=99ve been talking about interest in DNSSD, it might be = worth mentioning that yesterday evening there was a presentation at WWDC = on improvements that have been done to Bonjour in the new release of the = software that was announced on Monday. You can see the presentation = here: https://developer.apple.com/videos/play/wwdc2019/713/ It will refuse to play it on Chrome, but you can download it with the = link here: = https://devstreaming-cdn.apple.com/videos/wwdc/2019/713b310k72bjpcmz6xn/71= 3/713_sd_advances_in_networking_part_2.mp4?dl=3D1 = The whole presentation is really good stuff, but the part that is of = particular interest to the WG would be from about 1:00 to about 3:00, = where Erik (whom many of you probably know) describes the new feature. = The new feature is an implementation of the work we=E2=80=99ve done = here, including DNS Push and the DNS Discovery Proxy. This is really = cool stuff. The code for the Discovery Proxy, along with instructions for how to = install it, is here: https://github.com/IETF-Hackathon/mDNSResponder/blob/master/README.md = Fair warning: the developer seed is a seed, use it at your own risk. --Apple-Mail=_F13F26AC-E883-4E87-B18B-5DAE6447DFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since= we=E2=80=99ve been talking about interest in DNSSD, it might be worth = mentioning that yesterday evening there was a presentation at WWDC on = improvements that have been done to Bonjour in the new release of the = software that was announced on Monday.   You can see the = presentation here:

https://developer.apple.com/videos/play/wwdc2019/713/
=

It will refuse to = play it on Chrome, but you can download it with the link here: https://devstreaming-cdn.apple.com/videos/wwdc/2019/713b310k72b= jpcmz6xn/713/713_sd_advances_in_networking_part_2.mp4?dl=3D1

The whole presentation = is really good stuff, but the part that is of particular interest to the = WG would be from about 1:00 to about 3:00, where Erik (whom many of you = probably know) describes the new feature.   The new feature is an = implementation of the work we=E2=80=99ve done here, including DNS Push = and the DNS Discovery Proxy.   This is really cool stuff.

The code for the = Discovery Proxy, along with instructions for how to install it, is = here:

https://github.com/IETF-Hackathon/mDNSResponder/blob/master/REA= DME.md

Fair = warning: the developer seed is a seed, use it at your own = risk.

= --Apple-Mail=_F13F26AC-E883-4E87-B18B-5DAE6447DFD9-- From nobody Fri Jun 7 16:11:27 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B78120161 for ; Fri, 7 Jun 2019 16:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 9KtiFTa-pCaD for ; Fri, 7 Jun 2019 16:11:24 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 074E512002E for ; Fri, 7 Jun 2019 16:11:23 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id t64so2313747qkh.1 for ; Fri, 07 Jun 2019 16:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QfH+H7rsIEF0357FclihJJv5KfyDq5dMIW56Vw+5xNM=; b=LWE7r3somY8hD10vI3nZ4oPEZdQmRTgutf98dyrm24qwuBJ3084GoRGCmRda7hiM6L r0yllNitYgTStPihSCctfy8Ly+l/borhJ0s9aXfYBEiEwllCcyUqYC2mTj/c9Wok7GM4 W/iUtu+T+2T75xFuLhZWffAoB5ZqDUDWihzWkht+1wQFxIjaq92RMaaWlGSdcDpXvKh9 x3mjSGA+ZcX/KBLFU41EWAhgTdQWHQp6mm/JzKuGJ/JGioaQuuSZ8fwc0HABY5k5ExXt w8rUQDRP58kdtePrVdUrdvnoytvyCrQy8N3Qn0V3x5y5Mirb0sJM/CHDclSxEyIr5kyC /jNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QfH+H7rsIEF0357FclihJJv5KfyDq5dMIW56Vw+5xNM=; b=Lx6TiHGB9sQnDOBUwjQgR+dETiF8CTR+xBBF0ZsXr9Sf7QqelRRt8tA/8Rui1tgR9o 7DwdiGodsrQh8bpoSzDaIMPEXP7Mbu0Lyvoi8jfGnsaIeKYm7Q05C3HzBsm97/wCrqMG qd6K7dyzhrADy2oMGGVszRjbVGSgf4cz3kyyyq5vRAbp2aFWwlgvRQFpeHrxwWHUmAhP CzwTd3Iyc0SGU7NQ1z2dJ6vPHMlEFoW7ga0RlR6ySxGwwO/nyns9zhvBboDlVgsEvBi8 Mbb9lbb506gkLsvITi8JYw9iEaeS0BDmDGOC+VKKLVs4aZEB/StXCBGgUnvx9s3OjbWa 68xQ== X-Gm-Message-State: APjAAAX+cl60Ceiz+xbjBQcZKRtCxwHGcFob7CrwUEsH7WlLAJfbywj8 0qKKK/Vu6uixo4zGzlfci4CAl6Kn7s4dBQ== X-Google-Smtp-Source: APXvYqxfOIiTYRsvxP1ABdqoIelRpbf3vRC7zoK5+HEDxFUpvrUzPfaLBMfyi5Vccrzt9WpZyQy+bw== X-Received: by 2002:ae9:f503:: with SMTP id o3mr11598351qkg.345.1559949082881; Fri, 07 Jun 2019 16:11:22 -0700 (PDT) Received: from [10.0.30.16] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id j66sm451560qkf.86.2019.06.07.16.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 16:11:22 -0700 (PDT) From: Ted Lemon Message-Id: <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_08ED36AB-7931-4B9B-8570-9F36F06D7825" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Jun 2019 19:11:20 -0400 In-Reply-To: <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> Cc: Tom Pusateri , DNSSD To: Olafur Gudmundsson References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WG participation (or lack there of) 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, 07 Jun 2019 23:11:26 -0000 --Apple-Mail=_08ED36AB-7931-4B9B-8570-9F36F06D7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 31, 2019, at 8:33 PM, Olafur Gudmundsson wrote: > I think you are right and with only 2 people interested in the work it = is time to close the WG=20 It is a concern to me that the number of people who are interested in = this and paying attention to the mailing list and replying seems low, = but at the same time work is going on to deploy our work in the = industry. All of the major O.S. vendors support it. One option would = be to go forward with the remaining work as ISE documents, with the = potential that the IETF might want to update them later. I would be curious to know your opinion on this: do you feel that you = would rather that this stuff not be documented, or are you concerned = that there aren=E2=80=99t enough people here doing review? --Apple-Mail=_08ED36AB-7931-4B9B-8570-9F36F06D7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 31, 2019, at 8:33 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:
I think you = are right and with only 2 people interested in the work it is time to = close the WG 

It is a concern to me that the number of people who are = interested in this and paying attention to the mailing list and replying seems low, but at the same time work is going on to = deploy our work in the industry.   All of the major O.S. vendors = support it.   One option would be to go forward with the remaining = work as ISE documents, with the potential that the IETF might want to = update them later.

I would = be curious to know your opinion on this: do you feel that you would = rather that this stuff not be documented, or are you concerned that = there aren=E2=80=99t enough people here doing review?

= --Apple-Mail=_08ED36AB-7931-4B9B-8570-9F36F06D7825-- From nobody Sat Jun 8 01:20:31 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD6120128 for ; Sat, 8 Jun 2019 01:20:30 -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_HELO_NONE=0.001, 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 KmRVFxHQj08B for ; Sat, 8 Jun 2019 01:20:29 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 EC23712008F for ; Sat, 8 Jun 2019 01:20:28 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id a21so3688625ljh.7 for ; Sat, 08 Jun 2019 01:20:28 -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=Q4B2M8Cds356gPsxeZ2WYIg7QmaWozlcEFwZnKrDf8Y=; b=PQlbVaZitH4+3/bU2gcRZN1Y6gM5YSGoyXbLmocYlgiy5LLhCvXnVhZs1ajNTGjYxc hUIOTOfr3zoHAd055tt6QW7Qv48sQiuPkPrz7u1HaZyh08p+ONs230GzYyiVqquM2Tp4 7lRPly/fV/N5Fza4NNPM/kadisY1w4Im6x9ZvCtjxv6Wdao6THMFCuKees98WpLSUqBM Q4nvd/ya5W84/7Zi8WIrobGZAJT8yiDqNPTplGoTcE9RXT/qbU27bVJ6G5RMklq++F6/ 2TWvTuMH4IQ17qXW+DYEqAnofhHtZntdYcUuVfxq3pnNYUQKqgs3sEMoMr6rQDUTY2rl Na2Q== 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=Q4B2M8Cds356gPsxeZ2WYIg7QmaWozlcEFwZnKrDf8Y=; b=IrwmOn8qHxHSuEXUno7owBgiIEwVU0DhPFP+cXEEsuUO2gDvhmkK/TKsu95l6mgK1W I9TKO8NzoDYIeFtVMenJOgspFRBlvUjrZOqfc6fZju6lOiT4Rz4W8l62u+lDRuC2Bfa5 VXI1DN6felCuTJ7suWl47a81XAp8ygLH8+tTEh+jkibz6WNq+mb8jsCKIQ3VXhXl7P1C WFnVqYczjELpTuWndQFzu9+eP+5cWXmhBrC9tZ+yt/kJL5fzCirz8FuwHZSOdetsVh+D +cUWqD2cr/V86TXzwUt41WRwsRuj1//blbdobYRrH2W9sj13sF2STMhC3jVuuZc6Jzff PaXQ== X-Gm-Message-State: APjAAAWI+dRs18RNA1KEs63j9v5livFG3db8kZG8A60Y6Lwzb+bJouou vRJuW1Mo6OkYrfUuiam2xLRegbVDbu9sln21akgOM6zl X-Google-Smtp-Source: APXvYqxlNPRzlo4hGm/DOLeZx4/5JPI6rhVS+ZIz06m5SoEecW3swv0utMzd8EHAqUOMCKnjrcI8IR4eMaLlVL2BRV8= X-Received: by 2002:a2e:91c5:: with SMTP id u5mr18976316ljg.65.1559982027111; Sat, 08 Jun 2019 01:20:27 -0700 (PDT) MIME-Version: 1.0 References: <76E9B94C-B722-4FD1-ADE8-21DCA6299065@fugue.com> In-Reply-To: <76E9B94C-B722-4FD1-ADE8-21DCA6299065@fugue.com> From: David Schinazi Date: Sat, 8 Jun 2019 10:20:15 +0200 Message-ID: To: Ted Lemon Cc: DNSSD Content-Type: multipart/alternative; boundary="00000000000094ff4d058acb9e4e" Archived-At: Subject: Re: [dnssd] DNSSD at WWDC 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, 08 Jun 2019 08:20:31 -0000 --00000000000094ff4d058acb9e4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the record it plays fine for me on Chrome (on a Mac). Congratulations to everyone at Apple for a great talk, I'm excited to see the working group's work ship to billions of devices. On Fri, Jun 7, 2019 at 3:26 PM Ted Lemon wrote: > Since we=E2=80=99ve been talking about interest in DNSSD, it might be wor= th > mentioning that yesterday evening there was a presentation at WWDC on > improvements that have been done to Bonjour in the new release of the > software that was announced on Monday. You can see the presentation her= e: > > https://developer.apple.com/videos/play/wwdc2019/713/ > > It will refuse to play it on Chrome, but you can download it with the lin= k > here: > https://devstreaming-cdn.apple.com/videos/wwdc/2019/713b310k72bjpcmz6xn/7= 13/713_sd_advances_in_networking_part_2.mp4?dl=3D1 > > The whole presentation is really good stuff, but the part that is of > particular interest to the WG would be from about 1:00 to about 3:00, whe= re > Erik (whom many of you probably know) describes the new feature. The ne= w > feature is an implementation of the work we=E2=80=99ve done here, includi= ng DNS > Push and the DNS Discovery Proxy. This is really cool stuff. > > The code for the Discovery Proxy, along with instructions for how to > install it, is here: > > https://github.com/IETF-Hackathon/mDNSResponder/blob/master/README.md > > > Fair warning: the developer seed is a seed, use it at your own risk. > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --00000000000094ff4d058acb9e4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the record it plays fine for me on Chrome (on a Mac).<= div>
Congratulations to everyone at Apple for a great talk, I= 'm excited to see the working group's work ship to billions of devi= ces.

On Fri, Jun 7, 2019 at 3:26 PM Ted Lemon <mellon@fugue.com> wrote:
= Since we=E2=80=99ve been talking about interest in DNSSD, it might be worth= mentioning that yesterday evening there was a presentation at WWDC on impr= ovements that have been done to Bonjour in the new release of the software = that was announced on Monday. =C2=A0 You can see the presentation here:

It will refuse to play it on Chrome, but y= ou can download it with the link here:=C2=A0https://devstreaming-cdn.ap= ple.com/videos/wwdc/2019/713b310k72bjpcmz6xn/713/713_sd_advances_in_network= ing_part_2.mp4?dl=3D1

The whole presentation i= s really good stuff, but the part that is of particular interest to the WG = would be from about 1:00 to about 3:00, where Erik (whom many of you probab= ly know) describes the new feature. =C2=A0 The new feature is an implementa= tion of the work we=E2=80=99ve done here, including DNS Push and the DNS Di= scovery Proxy. =C2=A0 This is really cool stuff.

T= he code for the Discovery Proxy, along with instructions for how to install= it, is here:

<= br>
Fair warning: the developer seed is a seed, use it at your ow= n risk.

_________________________________________= ______
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--00000000000094ff4d058acb9e4e-- From nobody Tue Jun 11 08:13:52 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07F120181 for ; Tue, 11 Jun 2019 08:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni.lu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6L5NsNWAsGc for ; Tue, 11 Jun 2019 08:13:45 -0700 (PDT) Received: from smtp2.uni.lu (smtp2.uni.lu [IPv6:2001:a18:a:c5::e]) (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 64FB81200E5 for ; Tue, 11 Jun 2019 08:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1560266025; x=1591802025; h=to:references:from:subject:cc:message-id:date: mime-version:in-reply-to; bh=qFrofq9KczaVfbZmtR2BhhBiozMAH9AHxSz6tGF9Je4=; b=W+mUSQH/66OFbOjwybcVbonoTuJa4aZ8KNRTCPVchLLepzun6v0lSlKX l9Zhk4gmtv/A/099F63+z2sDvSuFfVID5+GvgnMWQfWJXRK6yksOGRcHx Et6Nuor0HC6zrZFcWuDNquxItmdOLeN5HYleSmuSLUE3mCU2zSCqEEg8u ITaSMsWjM4Fh7oqn+CGs+bK3U56IxdH01m+R70wVNb6RcrAHrBGBjfI+a F+kzfjbMkYqKonw1yhgljinBPM6ay2knDX81jdYkL6w1eHnW+ynnMpZmy RdnDuuNtI5Nw4h2XMxbRN+xbHkf6P01EYRoezijeRnKw3ZhzsOfifqn2j Q==; Authentication-Results: smtp2.uni.lu; spf=Fail smtp.mailfrom=daniel.kaiser@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu X-IronPort-AV: E=Sophos; i="5.63,579,1557180000"; d="scan'208,217"; a="20893781" To: References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> From: Daniel KAISER CC: Ted Lemon , Christian Huitema Message-ID: Date: Tue, 11 Jun 2019 17:13:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> Content-Type: multipart/alternative; boundary="------------43747CAD85FF0A3469E8A505" Content-Language: en-US X-Originating-IP: [10.240.10.16] X-ClientProxiedBy: Ryder2017.uni.lux (2001:a18:a:90::72) To lydia2017.uni.lux (2001:a18:a:90::6f) Archived-At: Subject: [dnssd] WWDC / Bonjour Privacy 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, 11 Jun 2019 15:13:50 -0000 --------------43747CAD85FF0A3469E8A505 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Regarding the privacy aspects of (m)DNS-SD: I still think it would be beneficial to finalize a document on a privacy-extension, and I still want to work on that. I agree, the lack of feedback within the group is a problem; we have come up with quite a few different proposals and there is no clear "favorite". Also, I see the problem that we try to solve too many use cases with a single specification (p2p mobile devices, classical  DNS server, printer, ...). For P2P applications like the tic-tac-toe example from the WWDC talks, the PSK could be extracted from the TLS connection and be used to derive a secret for obfuscating the service related information for the (next) discovery process. The interface matches the one from our proposal for a DNS-SD/mDNS based manually authenticated device pairing protocol. We could either go in the TLS/ESNI direction or stick with our older proposals and seamlessly integrate a privacy extension into mDNS-SD / Bonjour. Listening to the great talks by Apple I wonder if Apple is interested in working with us on a specification that would fit Apple's use cases of Bonjour. If someone is interested, I would be happy to collaborate. (However, as I work at a University and the projects I am involved in currently are not directly related to (m)DNS-SD, the time I can spend on this topic is limited until I find a matching project.) Kind regards, Daniel On 6/8/19 1:11 AM, Ted Lemon wrote: > On May 31, 2019, at 8:33 PM, Olafur Gudmundsson > wrote: >> I think you are right and with only 2 people interested in the work >> it is time to close the WG > > It is a concern to me that the number of people who are interested in > this and paying attention to the mailing list and /replying/ seems > low, but at the same time work is going on to deploy our work in the > industry.   All of the major O.S. vendors support it.   One option > would be to go forward with the remaining work as ISE documents, with > the potential that the IETF might want to update them later. > > I would be curious to know your opinion on this: do you feel that you > would rather that this stuff not be documented, or are you concerned > that there aren’t enough people here doing review? > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Dr. Daniel Kaiser Research Associate SnT- Interdisciplinary Centre for Security, Reliability and Trust University of Luxembourg Maison du Nombre (MNO) 6, avenue de la Fonte L-4364 Esch-sur-Alzette Office: E02 0225-010 --------------43747CAD85FF0A3469E8A505 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Regarding the privacy aspects of (m)DNS-SD:
I still think it would be beneficial to finalize a document on a privacy-extension,
and I still want to work on that.

I agree, the lack of feedback within the group is a problem;
we have come up with quite a few different proposals and there is no clear "favorite".
Also, I see the problem that we try to solve too many use cases with a single specification
(p2p mobile devices, classical  DNS server, printer, ...).

For P2P applications like the tic-tac-toe example from the WWDC talks,
the PSK could be extracted from the TLS connection and be used to derive a secret for obfuscating the
service related information for the (next) discovery process.
The interface matches the one from our proposal for a DNS-SD/mDNS based manually authenticated
device pairing protocol.
We could either go in the TLS/ESNI direction or stick with our older proposals and seamlessly
integrate a privacy extension into mDNS-SD / Bonjour.

Listening to the great talks by Apple I wonder if Apple is interested in working with us on
a specification that would fit Apple's use cases of Bonjour.

If someone is interested, I would be happy to collaborate.
(However, as I work at a University and the projects I am involved in currently are not directly related
to (m)DNS-SD, the time I can spend on this topic is limited until I find a matching project.)

Kind regards,
Daniel



On 6/8/19 1:11 AM, Ted Lemon wrote:
On May 31, 2019, at 8:33 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:
I think you are right and with only 2 people interested in the work it is time to close the WG 

It is a concern to me that the number of people who are interested in this and paying attention to the mailing list and replying seems low, but at the same time work is going on to deploy our work in the industry.   All of the major O.S. vendors support it.   One option would be to go forward with the remaining work as ISE documents, with the potential that the IETF might want to update them later.

I would be curious to know your opinion on this: do you feel that you would rather that this stuff not be documented, or are you concerned that there aren’t enough people here doing review?


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


-- 

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

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010
--------------43747CAD85FF0A3469E8A505-- From nobody Tue Jun 11 08:19:40 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B295B12025B for ; Tue, 11 Jun 2019 08:19:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 KNL6C6qQRzIE for ; Tue, 11 Jun 2019 08:19:36 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 10BB2120258 for ; Tue, 11 Jun 2019 08:19:36 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id g18so7901243qkl.3 for ; Tue, 11 Jun 2019 08:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+t0io/iUAPZnFS2wTiXCPQGysVLiO5H9t5TwXTbVX/g=; b=FNCoR2bS633l8/BOViZ3axw6TYoJGZA8Xx99Kb8EcR77pln7tBRL8Gpva85kxEH/HI FbTdXsPd4EBlIWkSVk0t+/mzoiLHKku0tPehW+wQo9xnFuqel8zXsMkexwmva9FObnNb gn9mc3/LFX+Q2ImmjfXpTz7fpjwzD8P8BOhfTDUReLdRBsrHHpeENXRUb/lUt55SYoRl f1pY5HHcmfyq5qHfhabJ7jCuim1ZKrfGnJXiu43mLmXprP367pLDArZwR9aV37wmOy3X agJW+DSruLlY744FpUJFsYjgu5ZZGuCdE9U9Jc8GL5xHftuQgym+Wcu/ANfjAo4w7xM+ ZNmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+t0io/iUAPZnFS2wTiXCPQGysVLiO5H9t5TwXTbVX/g=; b=OdbMEfmt764ELQVZZB/POWyCzGhL9U7mlehNWYMX8ZEKng1LJCaQ2V9sFmZsB/b/xj jwfl21OZnsPVJhUr4vlW70Gkly7OmlxzretWshHHvSzkv2PVeL6XQN5IWxL9tQKSTWYY 0WA6slxDIf1+F/ewk7k8xoctI1mwoo6HEbUYoefmGRU27flIbTfvcp9pcttcDvWdyXzK 9U2RK0jqc/cOex1SaXX8/mYJAsB4lSNxQ5/9XBDMvXrHn1s8/EQ62RdFS8l28pVbixzh g25knHBnz8HVtJkE4CpD3rEjfc4oyEp7QJ8m9lscwm1h9hEnIwDPnV0iFshr3dn+rPU1 pudQ== X-Gm-Message-State: APjAAAU5hvDNxA0ZN5/nlrLHrSbcSwfaZF5OkORfpaHLYdLDXiG0GGzn IbQYd/uG1QvQiiDEy/UNZSfqQebf57M= X-Google-Smtp-Source: APXvYqyTmwoegfaiZJSm74eB1wxBnL63RakG6s7AdwQZpbo39roZV6uq5iJgwznlgqpfqnTYcHDt0A== X-Received: by 2002:a37:e0d:: with SMTP id 13mr21962188qko.83.1560266375049; Tue, 11 Jun 2019 08:19:35 -0700 (PDT) Received: from [192.168.8.100] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v30sm3235859qtk.45.2019.06.11.08.19.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 08:19:34 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0B7B362D-941F-46E1-9F5A-05F6CE3FD58E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Jun 2019 11:19:33 -0400 In-Reply-To: Cc: dnssd@ietf.org, Christian Huitema To: Daniel KAISER References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WWDC / Bonjour Privacy 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, 11 Jun 2019 15:19:39 -0000 --Apple-Mail=_0B7B362D-941F-46E1-9F5A-05F6CE3FD58E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Daniel. IIRC, some folks at Apple have been involved in = working on the spec. I think part of the radio silence that you=E2=80=99= re hearing is that the Apple product cycle is such that the period from = March to June is actually a very busy time, and so there just aren=E2=80=99= t cycles for IETF between the spring and summer meetings. > On Jun 11, 2019, at 11:13 AM, Daniel KAISER = wrote: >=20 > Regarding the privacy aspects of (m)DNS-SD: > I still think it would be beneficial to finalize a document on a = privacy-extension, > and I still want to work on that. >=20 > I agree, the lack of feedback within the group is a problem; > we have come up with quite a few different proposals and there is no = clear "favorite". > Also, I see the problem that we try to solve too many use cases with a = single specification > (p2p mobile devices, classical DNS server, printer, ...). >=20 > For P2P applications like the tic-tac-toe example from the WWDC talks, > the PSK could be extracted from the TLS connection and be used to = derive a secret for obfuscating the > service related information for the (next) discovery process. > The interface matches the one from our proposal for a DNS-SD/mDNS = based manually authenticated > device pairing protocol. > We could either go in the TLS/ESNI direction or stick with our older = proposals and seamlessly > integrate a privacy extension into mDNS-SD / Bonjour. >=20 > Listening to the great talks by Apple I wonder if Apple is interested = in working with us on > a specification that would fit Apple's use cases of Bonjour. >=20 > If someone is interested, I would be happy to collaborate. > (However, as I work at a University and the projects I am involved in = currently are not directly related > to (m)DNS-SD, the time I can spend on this topic is limited until I = find a matching project.) >=20 > Kind regards, > Daniel >=20 >=20 >=20 > On 6/8/19 1:11 AM, Ted Lemon wrote: >> On May 31, 2019, at 8:33 PM, Olafur Gudmundsson > wrote: >>> I think you are right and with only 2 people interested in the work = it is time to close the WG=20 >>=20 >> It is a concern to me that the number of people who are interested in = this and paying attention to the mailing list and replying seems low, = but at the same time work is going on to deploy our work in the = industry. All of the major O.S. vendors support it. One option would = be to go forward with the remaining work as ISE documents, with the = potential that the IETF might want to update them later. >>=20 >> I would be curious to know your opinion on this: do you feel that you = would rather that this stuff not be documented, or are you concerned = that there aren=E2=80=99t enough people here doing review? >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 > --=20 >=20 > Dr. Daniel Kaiser > Research Associate > SnT- Interdisciplinary Centre for Security, Reliability and Trust >=20 > University of Luxembourg > Maison du Nombre (MNO) > 6, avenue de la Fonte > L-4364 Esch-sur-Alzette > Office: E02 0225-010 --Apple-Mail=_0B7B362D-941F-46E1-9F5A-05F6CE3FD58E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Daniel.   IIRC, some folks at Apple have been involved in working on the spec.   I = think part of the radio silence that you=E2=80=99re hearing is that the = Apple product cycle is such that the period from March to June is = actually a very busy time, and so there just aren=E2=80=99t cycles for = IETF between the spring and summer meetings.

On Jun = 11, 2019, at 11:13 AM, Daniel KAISER <daniel.kaiser@uni.lu> wrote:

=20 =20
Regarding the privacy aspects of (m)DNS-SD:
I still think it would be beneficial to finalize a document on a privacy-extension,
and I still want to work on that.

I agree, the lack of feedback within the group is a problem;
we have come up with quite a few different proposals and there is no clear "favorite".
Also, I see the problem that we try to solve too many use cases with a single specification
(p2p mobile devices, classical  DNS server, printer, ...).

For P2P applications like the tic-tac-toe example from the WWDC talks,
the PSK could be extracted from the TLS connection and be used to derive a secret for obfuscating the
service related information for the (next) discovery process.
The interface matches the one from our proposal for a DNS-SD/mDNS based manually authenticated
device pairing protocol.
We could either go in the TLS/ESNI direction or stick with our older proposals and seamlessly
integrate a privacy extension into mDNS-SD / Bonjour.

Listening to the great talks by Apple I wonder if Apple is interested in working with us on
a specification that would fit Apple's use cases of Bonjour.

If someone is interested, I would be happy to collaborate.
(However, as I work at a University and the projects I am involved in currently are not directly related
to (m)DNS-SD, the time I can spend on this topic is limited until I find a matching project.)

Kind regards,
Daniel



On 6/8/19 1:11 AM, Ted Lemon = wrote:
On May 31, 2019, at 8:33 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:
I think you are right and with = only 2 people interested in the work it is time to close the = WG 

It is a concern to me that the number of people = who are interested in this and paying attention to the mailing list and replying seems low, but at the same time work is going = on to deploy our work in the industry.   All of the major O.S. vendors support it.   One option would be to go forward = with the remaining work as ISE documents, with the potential that the IETF might want to update them later.

I would be curious to know your opinion on this: = do you feel that you would rather that this stuff not be documented, or are you concerned that there aren=E2=80=99t = enough people here doing review?


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


--=20

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

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010

= --Apple-Mail=_0B7B362D-941F-46E1-9F5A-05F6CE3FD58E-- From nobody Tue Jun 11 11:26:13 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C912018D for ; Tue, 11 Jun 2019 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni.lu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcYt7fKaZ9vi for ; Tue, 11 Jun 2019 11:26:08 -0700 (PDT) Received: from smtp1.uni.lu (smtp1.uni.lu [IPv6:2001:a18:a:c5::d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD19D120099 for ; Tue, 11 Jun 2019 11:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1560277567; x=1591813567; h=subject:references:from:cc:to:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mNyIhGekIdO3huf/Coqo2c5Oj5aaPPtxo7N9DZWK5dE=; b=HbjNUX5/Tlm58TDYy07mdvmi6gskOdT6CBFWC384cv/zpQZKridLmXC7 etcGpBESLSvyv6wP8cbbFHH5oEEw5IVMEHbV52Yz666l5pczfHrZL11i/ J/7pB2o5raUDAJwnZSrPMKLMkj/xIezUlkFl1Ytis9TcAghFkL2SNRAtw IkwwHcOWtQBTO+xlZ24Y1/eCFXTsetfhaesO6cxHdZIrmxFGYNIfuTL4R PUPUSX435RIXX3xCU3E7CwLQl4zTX8PlNO9mrOP3/ISibuwG7yEHVqm2F qs7uDQ8tBhwoGNlugBNTppGDkZsJBUX2wnKZSm6xRNS0xXCti3r+pBhL9 Q==; Authentication-Results: smtp1.uni.lu; spf=Fail smtp.mailfrom=daniel.kaiser@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu X-IronPort-AV: E=Sophos;i="5.63,362,1557180000"; d="scan'208";a="22103733" References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> From: Daniel KAISER CC: Ted Lemon , , Christian Huitema To: "dnssd@ietf.org" Message-ID: <90c77162-e7bb-5dc8-70d1-6775c55c2740@uni.lu> Date: Tue, 11 Jun 2019 20:25:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.244.9.68] X-ClientProxiedBy: Widow2017.uni.lux (2001:a18:a:90::71) To lydia2017.uni.lux (2001:a18:a:90::6f) Archived-At: Subject: Re: [dnssd] WWDC / Bonjour Privacy 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, 11 Jun 2019 18:26:11 -0000 On 6/11/19 5:19 PM, Ted Lemon wrote: > Thanks, Daniel. IIRC, some folks at Apple have been involved in working on the spec. Sorry, I forgot Bob Bradley is with Apple. I will ask him and Christian Christian Huitema for a phone conference. Imho, orally discussing our various approaches while taking Apple's use cases into consideration might help progressing and unifying the drafts. (Most likely, I will not be able to attend the next IETF meeting.) > I think part of the radio silence that you’re hearing is that the Apple product cycle is such that the period from March to June is actually a very busy time, and so there just aren’t cycles for IETF between the spring and summer meetings. > >> On Jun 11, 2019, at 11:13 AM, Daniel KAISER wrote: >> >> Regarding the privacy aspects of (m)DNS-SD: >> I still think it would be beneficial to finalize a document on a privacy-extension, >> and I still want to work on that. >> >> I agree, the lack of feedback within the group is a problem; >> we have come up with quite a few different proposals and there is no clear "favorite". >> Also, I see the problem that we try to solve too many use cases with a single specification >> (p2p mobile devices, classical DNS server, printer, ...). >> >> For P2P applications like the tic-tac-toe example from the WWDC talks, >> the PSK could be extracted from the TLS connection and be used to derive a secret for obfuscating the >> service related information for the (next) discovery process. >> The interface matches the one from our proposal for a DNS-SD/mDNS based manually authenticated >> device pairing protocol. >> We could either go in the TLS/ESNI direction or stick with our older proposals and seamlessly >> integrate a privacy extension into mDNS-SD / Bonjour. >> >> Listening to the great talks by Apple I wonder if Apple is interested in working with us on >> a specification that would fit Apple's use cases of Bonjour. >> >> If someone is interested, I would be happy to collaborate. >> (However, as I work at a University and the projects I am involved in currently are not directly related >> to (m)DNS-SD, the time I can spend on this topic is limited until I find a matching project.) >> >> Kind regards, >> Daniel >> >> >> >> On 6/8/19 1:11 AM, Ted Lemon wrote: >>> On May 31, 2019, at 8:33 PM, Olafur Gudmundsson > wrote: >>>> I think you are right and with only 2 people interested in the work it is time to close the WG >>> It is a concern to me that the number of people who are interested in this and paying attention to the mailing list and replying seems low, but at the same time work is going on to deploy our work in the industry. All of the major O.S. vendors support it. One option would be to go forward with the remaining work as ISE documents, with the potential that the IETF might want to update them later. >>> >>> I would be curious to know your opinion on this: do you feel that you would rather that this stuff not be documented, or are you concerned that there aren’t enough people here doing review? >>> >>> >>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >> -- >> >> Dr. Daniel Kaiser >> Research Associate >> SnT- Interdisciplinary Centre for Security, Reliability and Trust >> >> University of Luxembourg >> Maison du Nombre (MNO) >> 6, avenue de la Fonte >> L-4364 Esch-sur-Alzette >> Office: E02 0225-010 > -- Dr. Daniel Kaiser Research Associate SnT- Interdisciplinary Centre for Security, Reliability and Trust University of Luxembourg Maison du Nombre (MNO) 6, avenue de la Fonte L-4364 Esch-sur-Alzette Office: E02 0225-010 From nobody Tue Jun 11 11:32:23 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A412026C for ; Tue, 11 Jun 2019 11:32:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 KBBDzpsrHtnU for ; Tue, 11 Jun 2019 11:32:13 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 8E5491201EA for ; Tue, 11 Jun 2019 11:32:13 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id r6so8316799qkc.0 for ; Tue, 11 Jun 2019 11:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKjK47iQ0UqpoBIlBoyCUE5LDcsvHD5XulgoUxJ07IQ=; b=ItKrpiH/QpcWcewdzoy7+OVAbPwkAtNO6zuQa8aoWKRLZJp2SjUs/JXQjtn/+L/IxK OaG/YiTtV2VP+s3og8PiDx5tixFauf9scAF+jdw+ViObQHNJN1u2STXDbRhRaVR0TyTK UlZZ98qrVeYz2l+85l/04v8PB9G3tql6VkabZrDiQy44mMDYknhbaYjQoxcu5di7e3bK STAoo+PMhCMhYBPRB95e6IcIBkxxDrxaadujL9CE2ytVuOd7GbF6vx8sv/lg1MRlB0qu /NbZlUh0wZn2lqiyzb0m/QSYUjdMBuqhTWT6FeDh/fQTqogIwf9uNp46KacoX9em4pmX dd8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKjK47iQ0UqpoBIlBoyCUE5LDcsvHD5XulgoUxJ07IQ=; b=gOWpCNPP1CAnKQZWauj8UPGaqHxbHjCnRz77NyEG+THd84kYqk8LHlc+aduP9AGFpi ypIfJ1qs7RZImBmRMQCmtKj6vrUva23thIabF0hevq09kqHqWn+A5Rf4nzb4KODUDzi+ kL7LDNRvlR7U/Bl61tSe+a6r51bmBlyQ71ZZUtENU2cZc7/q4ncgTk7iBwHCHisocK/h Zced/uF27ucNjhAdaBiCiDVrQyLAdRapFMrET+U6B6mcin6L6fsrVlEsOptQ+DiNKo6k EKIELwOwA/xv1q6m6ekqjAUfv1qW8lfCRNAY4346dk/uZoz+lnvyL+pWffuGDTl8E+0E Q4kw== X-Gm-Message-State: APjAAAUcPMAV2DAljdmQConPvw8FJfvZRS0pnpbGclT+jwYylrTrfhF+ pxVUm4Yh9/C5AiKK/wgjOWXcTNuHfG4= X-Google-Smtp-Source: APXvYqxP5106fNzi/42N5BH79JpnPqzcIWe5PQun2sH5ikzdZcfotrjLabU8zWR+GDU3HohsCM95Qw== X-Received: by 2002:a37:9904:: with SMTP id b4mr59309880qke.159.1560277932574; Tue, 11 Jun 2019 11:32:12 -0700 (PDT) Received: from [192.168.8.100] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id c18sm6287277qkm.78.2019.06.11.11.32.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 11:32:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ted Lemon In-Reply-To: <90c77162-e7bb-5dc8-70d1-6775c55c2740@uni.lu> Date: Tue, 11 Jun 2019 14:32:10 -0400 Cc: "dnssd@ietf.org" , bradley=40apple.com@dmarc.ietf.org, Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: <128F1AE6-0F5F-47C3-B844-3C29F0543CBB@fugue.com> References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> <1E9E1477-1C80-4846-BB2C-1134F3D0865D@fugue.com> <90c77162-e7bb-5dc8-70d1-6775c55c2740@uni.lu> To: Daniel KAISER X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WWDC / Bonjour Privacy 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, 11 Jun 2019 18:32:21 -0000 On Jun 11, 2019, at 2:25 PM, Daniel KAISER wrote: > (Most likely, I will not be able to attend the next IETF meeting.) Unfortunate. Maybe we can arrange an online meeting during one of the = breakout session periods. From nobody Sat Jun 15 09:47:21 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB612004D; Sat, 15 Jun 2019 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=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 482r69f5j7U3; Sat, 15 Jun 2019 09:47:18 -0700 (PDT) Received: from 69-77-154-174.static.skybest.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 C788712001B; Sat, 15 Jun 2019 09:47:18 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 7BBAE32405; Sat, 15 Jun 2019 12:47:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) From: Tom Pusateri In-Reply-To: <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> Date: Sat, 15 Jun 2019 12:47:16 -0400 Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> To: Liang Xia X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 15 Jun 2019 16:47:21 -0000 Does this address your concerns? > On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >=20 > Will also address TLS comments. >=20 >> 3. In the section of Security Considerations: >> 1) you should also mention that TLS provides the anti-replay = protection >> service for DNS Push; I have added a 4th security service in the Security section: Anti-replay protection: TLS provides for the detection of and prevention against messages sent previously over a TLS connection (such as DNS Push Notifications). Prior messages cannot be re- sent at a later time as a form of a man-in-the-middle attack. >> 2) maybe you need to consider the client >> authentication to achieve policy control and detect illegal client; I have added a new paragraph in the Security section: As a consequence of requiring TLS, client certificate authentication and verification may also be enforced by the server for stronger client-server security or end-to-end security. However, recommendations for security in particular deployment scenarios are outside the scope of this document. >> 3) TLS >> WG are specifying the SNI encryption mechanism, will it influence = your TLS >> name authentication? SNI encryption has no effect on our use of TLS name authentication. Thanks, Tom From nobody Sat Jun 15 10:21:13 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B261200C5 for ; Sat, 15 Jun 2019 10:21:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 zRJG13qQ3wxq for ; Sat, 15 Jun 2019 10:21:10 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 D2E1C120094 for ; Sat, 15 Jun 2019 10:21:09 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id n11so6238924qtl.5 for ; Sat, 15 Jun 2019 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=YCZ3TuVl9kFipgEavgeyJHo+hc65/hMRcaK/2wbOTw+Cy12eWg/8BDx+py16uPP9AT QLrfSXhe0u2/e7869fDvgTaPcE1L95g8wVcYZJc+ehzVQnTvZ4nD10yVTy410KM37RGB hfNQelZPEM3BLimAPCXKjVgcDWUwCEPjLZYZJoGWWHHQeqfqJcYdRKIungKiEr6OR92V By8ZA0MExpSnb8DVQEK20CspZyGOUik6i5p0vAtc0TncPw7wO327yrenFXPGKg1JyFZF sRwwVimpZDFgkQ0U9i6+Bl2hPbN4tBhfTJrxFzEb5jiGYUATlNOHNbUYJkyt3g+j5B9n aMSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=gk1TWx40nyERFi6drGBBNVSwabX1nGX/1jjo/MNoXRu85T6VgCEZJw4I8My0bFuGMd dVPbLhIYk+MOoPKbN/8AvjAnTBWm+BgPot3obfrAzhdF9M19lmtPAwQ/mRJb/B3RHLcB M1sIXyT0E5+2qre23HIjzbNoliAbEepfxS3+rf6WyIt62iBtCpHLQ0HZkAD4gz9ouZjm bvnDBJY6fR1gsyGzeygOUMoIMi92NT3r2YcSN0pQdhnK3iLobmqblK/yj4fuJlJxoDoy x021K2WFjtKgpTvU9AfpmDw4ARuUlT1sL3FvtotoZGSxHaVSfFzkfvtex1pdJXPuurMD xswg== X-Gm-Message-State: APjAAAWxMD1rppDkzHNLzhw+uQvx3GAIE2R30NC3kEjVzdfVqux6EeGK j8o25cLQAorM8VHUJ2SF70mFZw== X-Google-Smtp-Source: APXvYqzj3s+iK/1/f2K5OAaHI0LK38owYcR4+0t3KF5zxcZgCS0H7XNziqK6Q8Oa2jSAjLL39BV6Xw== X-Received: by 2002:ac8:2809:: with SMTP id 9mr89368109qtq.4.1560619268852; Sat, 15 Jun 2019 10:21:08 -0700 (PDT) Received: from [10.0.30.11] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id y24sm1089873qty.96.2019.06.15.10.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:21:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G48) In-Reply-To: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> Date: Sat, 15 Jun 2019 13:21:06 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Tom Pusateri Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 15 Jun 2019 17:21:12 -0000 The primary motivation for using tls is opportunistic security. Authenticati= on would be interesting to add. SNI encryption would be interesting but I th= ink is a separate topic.=20 Client authorization might be useful in some cases, but generally is not don= e in DNS servers. To address these would require a security analysis of much= broader scope than is appropriate for this document. We=E2=80=99ve talked a= bout this in the context of homenet.=20 Sent from my iPhone > On Jun 15, 2019, at 12:47 PM, Tom Pusateri wrote: >=20 > Does this address your concerns? >=20 >> On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >>=20 >> Will also address TLS comments. >>=20 >>> 3. In the section of Security Considerations: >>> 1) you should also mention that TLS provides the anti-replay protection= >>> service for DNS Push; >=20 > I have added a 4th security service in the Security section: >=20 > Anti-replay protection: TLS provides for the detection of and > prevention against messages sent previously over a TLS connection > (such as DNS Push Notifications). Prior messages cannot be re- > sent at a later time as a form of a man-in-the-middle attack. >=20 >>> 2) maybe you need to consider the client >>> authentication to achieve policy control and detect illegal client; >=20 > I have added a new paragraph in the Security section: >=20 > As a consequence of requiring TLS, client certificate authentication > and verification may also be enforced by the server for stronger > client-server security or end-to-end security. However, > recommendations for security in particular deployment scenarios are > outside the scope of this document. >=20 >>> 3) TLS >>> WG are specifying the SNI encryption mechanism, will it influence your T= LS >>> name authentication? >=20 > SNI encryption has no effect on our use of TLS name authentication. >=20 > Thanks, > Tom >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jun 15 10:34:56 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95611200B3; Sat, 15 Jun 2019 10:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=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 WYAew6WLjhWL; Sat, 15 Jun 2019 10:34:40 -0700 (PDT) Received: from 69-77-154-174.static.skybest.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 53571120075; Sat, 15 Jun 2019 10:34:40 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 191DA32415; Sat, 15 Jun 2019 13:34:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) From: Tom Pusateri In-Reply-To: Date: Sat, 15 Jun 2019 13:34:38 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Ted Lemon X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 15 Jun 2019 17:34:42 -0000 I agree with your comments and think my additional text (in combination = with what was already there) is also in the spirit of your comments and = does not conflict. Are you suggesting there is a conflict? Thanks, Tom > On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >=20 > The primary motivation for using tls is opportunistic security. = Authentication would be interesting to add. SNI encryption would be = interesting but I think is a separate topic.=20 >=20 > Client authorization might be useful in some cases, but generally is = not done in DNS servers. To address these would require a security = analysis of much broader scope than is appropriate for this document. = We=E2=80=99ve talked about this in the context of homenet.=20 >=20 > Sent from my iPhone >=20 >> On Jun 15, 2019, at 12:47 PM, Tom Pusateri = wrote: >>=20 >> Does this address your concerns? >>=20 >>> On May 17, 2019, at 11:59 AM, Tom Pusateri = wrote: >>>=20 >>> Will also address TLS comments. >>>=20 >>>> 3. In the section of Security Considerations: >>>> 1) you should also mention that TLS provides the anti-replay = protection >>>> service for DNS Push; >>=20 >> I have added a 4th security service in the Security section: >>=20 >> Anti-replay protection: TLS provides for the detection of and >> prevention against messages sent previously over a TLS connection >> (such as DNS Push Notifications). Prior messages cannot be re- >> sent at a later time as a form of a man-in-the-middle attack. >>=20 >>>> 2) maybe you need to consider the client >>>> authentication to achieve policy control and detect illegal client; >>=20 >> I have added a new paragraph in the Security section: >>=20 >> As a consequence of requiring TLS, client certificate authentication >> and verification may also be enforced by the server for stronger >> client-server security or end-to-end security. However, >> recommendations for security in particular deployment scenarios are >> outside the scope of this document. >>=20 >>>> 3) TLS >>>> WG are specifying the SNI encryption mechanism, will it influence = your TLS >>>> name authentication? >>=20 >> SNI encryption has no effect on our use of TLS name authentication. >>=20 >> Thanks, >> Tom >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jun 15 10:40:16 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB89120075; Sat, 15 Jun 2019 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=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 MpZFJAOKGTSH; Sat, 15 Jun 2019 10:40:12 -0700 (PDT) Received: from 69-77-154-174.static.skybest.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 9855D120052; Sat, 15 Jun 2019 10:40:12 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 57EB332418; Sat, 15 Jun 2019 13:40:11 -0400 (EDT) From: Tom Pusateri Message-Id: <892F5AD2-8012-4127-9BD4-8DA57771E347@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) Date: Sat, 15 Jun 2019 13:40:10 -0400 In-Reply-To: Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org To: Ted Lemon References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 15 Jun 2019 17:40:15 -0000 --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By the way, you can see the updated version in context here (ignore the = date): https://github.com/pusateri/draft-ietf-dnssd-push = Thanks, Tom > On Jun 15, 2019, at 1:34 PM, Tom Pusateri wrote: >=20 > I agree with your comments and think my additional text (in = combination with what was already there) is also in the spirit of your = comments and does not conflict. Are you suggesting there is a conflict? >=20 > Thanks, > Tom >=20 >> On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >>=20 >> The primary motivation for using tls is opportunistic security. = Authentication would be interesting to add. SNI encryption would be = interesting but I think is a separate topic.=20 >>=20 >> Client authorization might be useful in some cases, but generally is = not done in DNS servers. To address these would require a security = analysis of much broader scope than is appropriate for this document. = We=E2=80=99ve talked about this in the context of homenet.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Jun 15, 2019, at 12:47 PM, Tom Pusateri = wrote: >>>=20 >>> Does this address your concerns? >>>=20 >>>> On May 17, 2019, at 11:59 AM, Tom Pusateri = wrote: >>>>=20 >>>> Will also address TLS comments. >>>>=20 >>>>> 3. In the section of Security Considerations: >>>>> 1) you should also mention that TLS provides the anti-replay = protection >>>>> service for DNS Push; >>>=20 >>> I have added a 4th security service in the Security section: >>>=20 >>> Anti-replay protection: TLS provides for the detection of and >>> prevention against messages sent previously over a TLS connection >>> (such as DNS Push Notifications). Prior messages cannot be re- >>> sent at a later time as a form of a man-in-the-middle attack. >>>=20 >>>>> 2) maybe you need to consider the client >>>>> authentication to achieve policy control and detect illegal = client; >>>=20 >>> I have added a new paragraph in the Security section: >>>=20 >>> As a consequence of requiring TLS, client certificate authentication >>> and verification may also be enforced by the server for stronger >>> client-server security or end-to-end security. However, >>> recommendations for security in particular deployment scenarios are >>> outside the scope of this document. >>>=20 >>>>> 3) TLS >>>>> WG are specifying the SNI encryption mechanism, will it influence = your TLS >>>>> name authentication? >>>=20 >>> SNI encryption has no effect on our use of TLS name authentication. >>>=20 >>> Thanks, >>> Tom >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >=20 --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 By = the way, you can see the updated version in context here (ignore the = date):

https://github.com/pusateri/draft-ietf-dnssd-push

Thanks,
Tom

On Jun 15, 2019, at 1:34 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

I = agree with your comments and think my additional text (in combination = with what was already there) is also in the spirit of your comments and = does not conflict. Are you suggesting there is a conflict?

Thanks,
Tom

On Jun 15, 2019, at 1:21 = PM, Ted Lemon <mellon@fugue.com> wrote:

The primary motivation for using tls is opportunistic = security. Authentication would be interesting to add. SNI encryption = would be interesting but I think is a separate topic.

Client authorization might be useful in some cases, but = generally is not done in DNS servers. To address these would require a = security analysis of much broader scope than is appropriate for this = document. We=E2=80=99ve talked about this in the context of homenet.

Sent from my iPhone

On Jun 15, 2019, at = 12:47 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Does this address your concerns?

On May 17, 2019, at = 11:59 AM, Tom Pusateri <pusateri@bangj.com> wrote:

Will also address TLS comments.

3. In the section of = Security Considerations:
1) you should also mention that = TLS provides the anti-replay protection
service for DNS = Push;

I have = added a 4th security service in the Security section:

Anti-replay protection:  TLS provides for the detection = of and
   prevention against messages sent = previously over a TLS connection
   (such = as DNS Push Notifications).  Prior messages cannot be re-
   sent at a later time as a form of a = man-in-the-middle attack.

2) maybe = you need to consider the client
authentication to achieve = policy control and detect illegal client;

I have added a new = paragraph in the Security section:

As a = consequence of requiring TLS, client certificate authentication
and verification may also be enforced by the server for = stronger
client-server security or end-to-end security. =  However,
recommendations for security in particular = deployment scenarios are
outside the scope of this = document.

3) TLS
WG = are specifying the SNI encryption mechanism, will it influence your = TLS
name authentication?

SNI encryption has = no effect on our use of TLS name authentication.

Thanks,
Tom


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


= --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700-- From nobody Sat Jun 15 10:43:27 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83A91200D6 for ; Sat, 15 Jun 2019 10:43:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jIbeA68kf_qY for ; Sat, 15 Jun 2019 10:43:23 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 EAD2B12008B for ; Sat, 15 Jun 2019 10:43:22 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id s22so3752858qkj.12 for ; Sat, 15 Jun 2019 10:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=dfnJa9AQchq4U9iZfyZ0DTKJjEola7ve+M6XMzsuqYmmC4BzOvZCdKxJIsw0SYQXzF ksUeHqYjD/ZhuFbxBOaMr0c6gS87alfiTRxauazhqhnYyiDSfDxI+DfV3U1JvXryYO2u o/R+x5qGqTl7psayYRgGZu+yBTlvIJB0OYf6XOX75n+9jxFd9gMjeXXIK5SS/NDiCjCx JgEJYsufJ0Fu5INC0pixgf1OwzAgIobWCB8MQipholYNhbvTCtD7z5V4S8ItEJe+90Ql 8/mlRbRp7iXwSSZXFW6N489KjyOfk2mfLJ3bY0AsnV4R8H0gqOaUvitMIne+de9xEUhq F0KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=FT/tkQ13nHOymj+YiaucVOhINpagVFucjzK98GEEyoPw3lGfoi/oj3AJ8LdYag5tI5 BuKgoQWCRbBRhcf1HrLKqEribZ7c5iqYkyE4CarP7L/suDjG973ewj4JdMxebVeonMuG wdiLN+SdLMCXhx0H486hFRB8vJ9Ws05KYrU+EkGZurdtQFsC0NwCH1BCUVOMDkeiFT5S bstOsc/hGauiO953Vq/Uf0JWeETOvAbt73vjRM0NpCmkCss4R+sE42OjXyX6KqHeFOia NMCWPWZr/duTTAi4QoZb/AAHUEbA5DItvwhL2/xwzEY85KiS+9oFdkYMM8qs9icxqREW 1Ddw== X-Gm-Message-State: APjAAAWTI52/0kwEYiE/YKC7t/hM8ts4G9fFU4tGTRqiSUCztMZrwKTu 6WOVAm9K1GKBStz6qVOVP8LB1A== X-Google-Smtp-Source: APXvYqxduMz/F4VLBvCq/u8InKOsH++SzrIXasMbWzAYZHKqluiJ/Q5CviuyBsxyY6z7rDIGQCKxIg== X-Received: by 2002:a05:620a:124c:: with SMTP id a12mr82150473qkl.336.1560620601971; Sat, 15 Jun 2019 10:43:21 -0700 (PDT) Received: from [10.0.30.11] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id k7sm2766294qth.88.2019.06.15.10.43.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:43:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G48) In-Reply-To: Date: Sat, 15 Jun 2019 13:43:20 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Tom Pusateri Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 15 Jun 2019 17:43:26 -0000 No, just chiming in. This was something I had to think about during the impl= ementation, so it=E2=80=99s familiar territory.=20 Sent from my iPhone > On Jun 15, 2019, at 1:34 PM, Tom Pusateri wrote: >=20 > I agree with your comments and think my additional text (in combination wi= th what was already there) is also in the spirit of your comments and does n= ot conflict. Are you suggesting there is a conflict? >=20 > Thanks, > Tom >=20 >> On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >>=20 >> The primary motivation for using tls is opportunistic security. Authentic= ation would be interesting to add. SNI encryption would be interesting but I= think is a separate topic.=20 >>=20 >> Client authorization might be useful in some cases, but generally is not d= one in DNS servers. To address these would require a security analysis of mu= ch broader scope than is appropriate for this document. We=E2=80=99ve talked= about this in the context of homenet.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Jun 15, 2019, at 12:47 PM, Tom Pusateri wrote: >>>=20 >>> Does this address your concerns? >>>=20 >>>> On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >>>>=20 >>>> Will also address TLS comments. >>>>=20 >>>>> 3. In the section of Security Considerations: >>>>> 1) you should also mention that TLS provides the anti-replay protectio= n >>>>> service for DNS Push; >>>=20 >>> I have added a 4th security service in the Security section: >>>=20 >>> Anti-replay protection: TLS provides for the detection of and >>> prevention against messages sent previously over a TLS connection >>> (such as DNS Push Notifications). Prior messages cannot be re- >>> sent at a later time as a form of a man-in-the-middle attack. >>>=20 >>>>> 2) maybe you need to consider the client >>>>> authentication to achieve policy control and detect illegal client; >>>=20 >>> I have added a new paragraph in the Security section: >>>=20 >>> As a consequence of requiring TLS, client certificate authentication >>> and verification may also be enforced by the server for stronger >>> client-server security or end-to-end security. However, >>> recommendations for security in particular deployment scenarios are >>> outside the scope of this document. >>>=20 >>>>> 3) TLS >>>>> WG are specifying the SNI encryption mechanism, will it influence your= TLS >>>>> name authentication? >>>=20 >>> SNI encryption has no effect on our use of TLS name authentication. >>>=20 >>> Thanks, >>> Tom >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Tue Jun 18 12:17:45 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94319120463; Tue, 18 Jun 2019 12:17:38 -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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156088545851.6808.11588917503573832044@ietfa.amsl.com> Date: Tue, 18 Jun 2019 12:17:38 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-20.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, 18 Jun 2019 19:17:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-20.txt Pages : 39 Date : 2019-06-18 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-20 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 21 10:10:06 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AA120033; Fri, 21 Jun 2019 10:09:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, Tim Wicinski , draft-ietf-dnssd-push@ietf.org, evyncke@cisco.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156113699565.17488.10859352688765859766.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2019 10:09:55 -0700 Archived-At: Subject: [dnssd] Last Call: (DNS Push Notifications) to Proposed Standard 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, 21 Jun 2019 17:09:56 -0000 The IESG has received a request from the Extensions for Scalable DNS Service Discovery WG (dnssd) to consider the following document: - 'DNS Push Notifications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jun 24 00:55:15 2019 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314721200EB; Mon, 24 Jun 2019 00:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NKNGkm7G0tzL; Mon, 24 Jun 2019 00:55:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1C2B5120088; Mon, 24 Jun 2019 00:55:04 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C4498432CF4F5A995E43; Mon, 24 Jun 2019 08:55:01 +0100 (IST) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Jun 2019 08:55:01 +0100 Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 15:53:58 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: Tom Pusateri CC: "draft-ietf-dnssd-push.all@ietf.org" , "dnssd@ietf.org" , IETF , "secdir@ietf.org" Thread-Topic: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 Thread-Index: AQHVDMmJ76Sy5YjtmUawwK/ZaNP/bKaclEoAgA4VfBA= Date: Mon, 24 Jun 2019 07:53:58 +0000 Message-ID: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> In-Reply-To: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [dnssd] =?gb2312?b?tPC4tDogIFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTE5?= 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, 24 Jun 2019 07:55:06 -0000 SGkgVG9tLA0KU29ycnkgZm9yIHJlc3BvbmRpbmcgeW91ciByZXNwb25zZSBlbWFpbCBwcm9tcHRs eS4NCg0KSSBoYXZlIGNoZWNrZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIC0yMCBkcmFmdCwgYW5kIHRo b3VnaHQgaXQgaGF2ZSBhZGRyZXNzZWQgYWxsIG15IHNlY3VyaXR5IGlzc3Vlcy4NClRoYW5rcyEN Cg0KQi5SLg0KRnJhbmsNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogVG9tIFB1c2F0 ZXJpIFttYWlsdG86cHVzYXRlcmlAYmFuZ2ouY29tXSANCreiy83KsbzkOiAyMDE5xOo21MIxNsjV IDA6NDcNCsrVvP7IyzogWGlhbGlhbmcgKEZyYW5rLCBOZXR3b3JrIFN0YW5kYXJkICYgUGF0ZW50 IERlcHQpIDxmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPg0Ks63LzTogZHJhZnQtaWV0Zi1kbnNz ZC1wdXNoLmFsbEBpZXRmLm9yZzsgZG5zc2RAaWV0Zi5vcmc7IElFVEYgPGlldGZAaWV0Zi5vcmc+ OyBzZWNkaXJAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbZG5zc2RdIFNlY2RpciB0ZWxlY2hhdCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTE5DQoNCkRvZXMgdGhpcyBhZGRyZXNzIHlvdXIg Y29uY2VybnM/DQoNCj4gT24gTWF5IDE3LCAyMDE5LCBhdCAxMTo1OSBBTSwgVG9tIFB1c2F0ZXJp IDxwdXNhdGVyaUBiYW5nai5jb20+IHdyb3RlOg0KPiANCj4gV2lsbCBhbHNvIGFkZHJlc3MgVExT IGNvbW1lbnRzLg0KPiANCj4+IDMuIEluIHRoZSBzZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zOg0KPj4gICAxKSB5b3Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IFRMUyBwcm92aWRl cyB0aGUgYW50aS1yZXBsYXkgcHJvdGVjdGlvbg0KPj4gICBzZXJ2aWNlIGZvciBETlMgUHVzaDsN Cg0KSSBoYXZlIGFkZGVkIGEgNHRoIHNlY3VyaXR5IHNlcnZpY2UgaW4gdGhlIFNlY3VyaXR5IHNl Y3Rpb246DQoNCkFudGktcmVwbGF5IHByb3RlY3Rpb246ICBUTFMgcHJvdmlkZXMgZm9yIHRoZSBk ZXRlY3Rpb24gb2YgYW5kDQogICAgICBwcmV2ZW50aW9uIGFnYWluc3QgbWVzc2FnZXMgc2VudCBw cmV2aW91c2x5IG92ZXIgYSBUTFMgY29ubmVjdGlvbg0KICAgICAgKHN1Y2ggYXMgRE5TIFB1c2gg Tm90aWZpY2F0aW9ucykuICBQcmlvciBtZXNzYWdlcyBjYW5ub3QgYmUgcmUtDQogICAgICBzZW50 IGF0IGEgbGF0ZXIgdGltZSBhcyBhIGZvcm0gb2YgYSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2su DQoNCj4+IDIpIG1heWJlIHlvdSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBjbGllbnQNCj4+ICAgYXV0 aGVudGljYXRpb24gdG8gYWNoaWV2ZSBwb2xpY3kgY29udHJvbCBhbmQgZGV0ZWN0IGlsbGVnYWwg Y2xpZW50Ow0KDQpJIGhhdmUgYWRkZWQgYSBuZXcgcGFyYWdyYXBoIGluIHRoZSBTZWN1cml0eSBz ZWN0aW9uOg0KDQpBcyBhIGNvbnNlcXVlbmNlIG9mIHJlcXVpcmluZyBUTFMsIGNsaWVudCBjZXJ0 aWZpY2F0ZSBhdXRoZW50aWNhdGlvbg0KICAgYW5kIHZlcmlmaWNhdGlvbiBtYXkgYWxzbyBiZSBl bmZvcmNlZCBieSB0aGUgc2VydmVyIGZvciBzdHJvbmdlcg0KICAgY2xpZW50LXNlcnZlciBzZWN1 cml0eSBvciBlbmQtdG8tZW5kIHNlY3VyaXR5LiAgSG93ZXZlciwNCiAgIHJlY29tbWVuZGF0aW9u cyBmb3Igc2VjdXJpdHkgaW4gcGFydGljdWxhciBkZXBsb3ltZW50IHNjZW5hcmlvcyBhcmUNCiAg IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCj4+IDMpIFRMUw0KPj4gICBX RyBhcmUgc3BlY2lmeWluZyB0aGUgU05JIGVuY3J5cHRpb24gbWVjaGFuaXNtLCB3aWxsIGl0IGlu Zmx1ZW5jZSB5b3VyIFRMUw0KPj4gICBuYW1lIGF1dGhlbnRpY2F0aW9uPw0KDQpTTkkgZW5jcnlw dGlvbiBoYXMgbm8gZWZmZWN0IG9uIG91ciB1c2Ugb2YgVExTIG5hbWUgYXV0aGVudGljYXRpb24u DQoNClRoYW5rcywNClRvbQ0KDQoNCg== From nobody Mon Jun 24 00:56:17 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8A120088; Mon, 24 Jun 2019 00:56:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <156136297038.17643.5252253391883114885@ietfa.amsl.com> Date: Mon, 24 Jun 2019 00:56:10 -0700 Archived-At: Subject: [dnssd] Secdir last call review of draft-ietf-dnssd-push-20 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, 24 Jun 2019 07:56:11 -0000 Reviewer: Liang Xia Review result: Ready The draft is ready. No more issues left from my side. From nobody Fri Jun 28 13:03:42 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AD5120904; Fri, 28 Jun 2019 13:03:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156175221593.21875.9525138908968318905@ietfa.amsl.com> Date: Fri, 28 Jun 2019 13:03:35 -0700 Archived-At: Subject: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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, 28 Jun 2019 20:03:36 -0000 Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dnssd-push-20 Reviewer: Robert Sparks Review Date: 2019-06-28 IETF LC End Date: 2019-07-05 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a Proposed Standard but with an Issue to consider before publication, Issue: The discussion of recursive resolvers in section 6.1 may need additional consideration. In particular, the recommendation to pass a received error code along to a client has, I think, some unintended consequences for the client. If the recursive server receives a NOTIMP, for example, passing that to the client tells the client the wrong thing about the server it is connected to. Perhaps it would be better for the recursive server to return SERVFAIL in this circumstance? (Similar to what it would do if it couldn't connect to the next server as described at the bottom of page 10). Nits: Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a 2119/8174 keyword. I suggest using lowercase 'not required' in this sentence. Page 7, Section 4, 3rd paragraph: The first sentence alludes to concerns about anonymous subscriptions, saying TCP alleviates those concerns. As written this is pretty vague. Can you expand on what you mean by an anonymous subscription in this context? Page 10, Section 6.1, first sentence: Suggest s/first step in DNS Push/first step in a DNS Push/ Page 15, last paragraph: Why MUST the server immediately terminate a connection in this situation? Just accepting the request seems safe - having subscription requests show up for the same name seems nearly idempotent, and only one PUSH would result from having multiple such subscriptions. Is this close an attempt to avoid resource denial attacks buy some node subscribing many times to the same thing? That feels extreme, especially since tearing down the connection would cancel other subscriptions the client already has established on that connection. Page 16, second paragraph: I suggest replacing the second sentence with something like "A name in a SUBSCRIBE message that matches only a literal CNAME in the zone will only receive notifications of changes to the CNAME (assuming the subscription asks for that type), and nothing else." Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP, the "(or equivalent for other protocols)" phrase should be removed.