From nobody Wed Jul 1 13:18:30 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15011A8787 for ; Wed, 1 Jul 2015 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bjcRvc_Col0m for ; Wed, 1 Jul 2015 13:18:28 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 CB9231A00C0 for ; Wed, 1 Jul 2015 13:18:27 -0700 (PDT) Received: by obbkm3 with SMTP id km3so35969182obb.1 for ; Wed, 01 Jul 2015 13:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ubcS+QE8gmWQMsP4jDQRO7JKvTp3FPT9GCV5ttNuaII=; b=xAIEZCMuF+bqCXz4/dopXqf8WMdNHyPGshn0EYt16MY2jhzER0wLKKBkaNX7nwjrpv D3f8FYFkDGy286Q2xfcNFoCBJy1XP/d2DZE/RqFe+oC+i9NiwNlufmlJn7NEJvw4S4FS Kr43+LydQhUDEq0L8lwx9Dlz6o91verB68hg4edji7abeugSl3yI676Z2vgF71Q+ZDDJ UK+WnGvZd5rIYK+FI54lMhqx7EVMTC7XTLPFUkuhqCuaHGB5PR7OjhtOKYlQpv+GsL1F ckyPVBofiOEZoUcCePvQeg/TUscQWKCtRs7niGds1wY9qIrHnLTVWq3/ye004LnzkyhG jioA== X-Received: by 10.202.104.211 with SMTP id o80mr25678907oik.19.1435781907312; Wed, 01 Jul 2015 13:18:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ck4sm1635184oeb.14.2015.07.01.13.18.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 13:18:25 -0700 (PDT) To: dnssd@ietf.org References: <20150619232740.1236.55980.idtracker@ietfa.amsl.com> From: Douglas Otis Message-ID: <55944B0F.5080100@gmail.com> Date: Wed, 1 Jul 2015 13:18:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] IETF 93 Preliminary Agenda - dnssd session X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:18:29 -0000 On 6/21/15 2:16 AM, Tim Chown wrote: > Hi, > > You may well have seen it elsewhere, but the preliminary IETF agenda is out. > > The dnssd meeting is currently scheduled for 9.00am-11.30am CEST on Wed 22nd July. We requested a 2 hour slot, but have been given more. > > If you have agenda items, please let me (or Ralph) know. > > Tim Dear Tim, This is past the Agenda cut-off, but it seems many concerns related to DNS-SD could be solved using DNS over QUIC as opposed to the DNSoD solution taken in dprive. Regards, Douglas Otis From nobody Sat Jul 4 14:25:14 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B71A1A4F; Sat, 4 Jul 2015 14:25: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] autolearn=ham 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 J_RiAd_Oz8Y7; Sat, 4 Jul 2015 14:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A851A1A16; Sat, 4 Jul 2015 14:25:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> Date: Sat, 04 Jul 2015 14:25:11 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 21:25:12 -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 Working Group of the IETF. Title : On Interoperation of Labels Between mDNS and DNS Author : Andrew Sullivan Filename : draft-ietf-dnssd-mdns-dns-interop-01.txt Pages : 10 Date : 2015-07-04 Abstract: Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-dns-interop-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 4 17:23:29 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E214A1B2A96 for ; Sat, 4 Jul 2015 17:23:27 -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] autolearn=ham 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 zhNUmtrBLkwZ for ; Sat, 4 Jul 2015 17:23:26 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 925A21A9084 for ; Sat, 4 Jul 2015 17:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 3DAEB10370 for ; Sun, 5 Jul 2015 00:23:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiDXFXjOgYF0 for ; Sun, 5 Jul 2015 00:23:23 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:22:842:8d1d:1802:aef6]) by mx2.yitter.info (Postfix) with ESMTPSA id 507181000B for ; Sun, 5 Jul 2015 00:23:23 +0000 (UTC) Date: Sat, 4 Jul 2015 20:23:21 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150705002321.GB48722@mx2.yitter.info> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 00:23:28 -0000 Hi, On Sat, Jul 04, 2015 at 02:25:11PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. > > Title : On Interoperation of Labels Between mDNS and DNS > Author : Andrew Sullivan > Filename : draft-ietf-dnssd-mdns-dns-interop-01.txt > Pages : 10 > Date : 2015-07-04 This draft attempts to deal with the issues that were raised to me about the previous versions. In particular, it tries to de-emphasise the worry about system-wide resolvers (without dismissing it completely) and to emphasise the issue of actual administration policies in the public DNS. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 6 18:25:19 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800ED1A887A for ; Mon, 6 Jul 2015 18:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ReEgFOuz4Q0q for ; Mon, 6 Jul 2015 18:25:15 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC581A8851 for ; Mon, 6 Jul 2015 18:25:15 -0700 (PDT) Received: by oiaf66 with SMTP id f66so99227595oia.3 for ; Mon, 06 Jul 2015 18:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rPfrlPJqhjib/Ssam2ZLNe6ubSyRLymtCXpO8lSMNc0=; b=lBPcvCu4SyYerK75cnvKjp62DnFEMVAo2YDV7dYw9E50odJiu2UkdEVUj0wk63+WFt HnvP5PlLozSl8CJ/J/ACyTTlcyzZKHQwgVSzHGDqCtPwtmWw8Y4pbGEzDXBZ5hw8PBXk oggCJyvFQRKPN0OIsyPhUtcwmifFv3s5STShiAwrPsvE9jmGYv8KEAFO1UsgIuMS8uc2 NaGldkfbaM9+a5c+qkCCHY4avWBCBP4BIvHPEvs8FB9B3UGr3gFS1bJRnXTwhLoAb85l Tbqasr7QPblIDs8ZfjevIxc2v4n8U/G70Kxp4EVfCzrqc9xXLXojxHfdQDMVUDr0MReu y2dw== X-Received: by 10.202.215.5 with SMTP id o5mr1365496oig.4.1436232314847; Mon, 06 Jul 2015 18:25:14 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id c203sm5280658oig.12.2015.07.06.18.25.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 18:25:13 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559B2A77.9030606@gmail.com> Date: Mon, 6 Jul 2015 18:25:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150705002321.GB48722@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 01:25:17 -0000 On 7/4/15 5:23 PM, Andrew Sullivan wrote: > Hi, > > On Sat, Jul 04, 2015 at 02:25:11PM -0700, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. >> >> Title : On Interoperation of Labels Between mDNS and DNS >> Author : Andrew Sullivan >> Filename : draft-ietf-dnssd-mdns-dns-interop-01.txt >> Pages : 10 >> Date : 2015-07-04 > This draft attempts to deal with the issues that were raised to me > about the previous versions. In particular, it tries to de-emphasise > the worry about system-wide resolvers (without dismissing it > completely) and to emphasise the issue of actual administration > policies in the public DNS. Dear Andrew, Why assume top level domains are always A-Labels? A scheme that visually conveys available services in list form for user selection is not well served with A-labels. Why not emphasize use of UTF-8 where possible to avoid rather messy conversion issues and resulting visual confusion. Your approach ignores two issues: 1) Dealing with look-alike spoofing can not depend upon registrar regulation or conversion rules. 2) The size of a response accessed with a DNS wildcard may lead to DDoS issues. Publishing prophylactic wildcards destroys the utility of the DNS-SD approach. An incongruity of mixing A-Labels with U-labels creates an unfriendly display of identifiers which does not help limit the size of the list response. The listing approach can be made safe with use of HTTP rather than DNS, or at the least DNS over QUIC. Until an inter-op document is more comprehensive, it is hard to see how this improves upon the current situation. DDoS and inadvertent disclosure issues are explained in: https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 Regards, Douglas Otis From nobody Mon Jul 6 19:42:53 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5703F1A8712 for ; Mon, 6 Jul 2015 19:42:52 -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] autolearn=ham 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 wLbd30lyJ7ni for ; Mon, 6 Jul 2015 19:42:50 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 154071A870C for ; Mon, 6 Jul 2015 19:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 45CD110012 for ; Tue, 7 Jul 2015 02:42:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho0MGy24hBOE for ; Tue, 7 Jul 2015 02:42:42 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id AEF771000B for ; Tue, 7 Jul 2015 02:42:42 +0000 (UTC) Date: Mon, 6 Jul 2015 22:42:40 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150707024239.GC52436@mx2.yitter.info> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559B2A77.9030606@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 02:42:52 -0000 On Mon, Jul 06, 2015 at 06:25:11PM -0700, Douglas Otis wrote: > Why assume top level domains are always A-Labels? Top level domains in the DNS are not always A-labels, because non-IDN LDH labels are not A-labels. But any IDN that gets into the root zone, at least as of any policy since 2003, will be an A-label. If you have any evidence of any case where that is not what ICANN (in its policy role) has instructed ICANN-IANA to do, I'd be interested to hear of it. > A scheme > that visually conveys available services in list form for > user selection is not well served with A-labels. That's a user presentation issue, not a lookup issue. An application ought, of course, to display such things as U-labels. U-labels and A-labels are freely interconvertable (there's no such thing as a U-label that does not have exactly one A-label). > Why not emphasize use of UTF-8 where possible to avoid > rather messy conversion issues and resulting visual > confusion. To begin with, not every way of writing something using UTF-8 is a U-label. Indeed, that's the _problem_ we're trying to deal with: mDNS encourages labels that are not and never will be U-labels. Second, you're never looking up a U-label, but an A-label; and this draft is about how to make lookups work in resolution systems that have different operational conventions. (Note that you could be looking up a UTF-8 string that happens to match a U-label. And you could do that in the DNS or you could do that in some other resolution system like mDNS. If you try to do it in most -- I won't say "all" -- of the high-level zones in the DNS, you will get NXDOMAIN if you get anything.) Finally, the idea that somehow emphasising UTF-8 is going to help in any way with conversion issues (messy or otherwise) or visual confusion is more than a little preposterous. > 1) Dealing with look-alike spoofing can not depend upon > registrar regulation or conversion rules. No, indeed, it can't, at least where non-registration resolution systems reside. It _can_ be ameliorated by registration rules (i.e. operations policy) if those are sufficiently well-specified. But there is absolutely no way, using DNS with IDNA or any other technology, that look-alike spoofing is going to be prevented in every case. And that is of course bound to be more challenging in a global lookup context than in a link-local context, if only because one has much more control in a link-local contest. > 2) The size of a response accessed with a DNS wildcard may > lead to DDoS issues. What in the world does this have to do with any of it? This is true when you're using DNS, regardless of whether there's a DNS-SD link. I don't think we need to explore the possibility of DDoS every time the magic string "DNS" appears in an Internet-Draft. > Publishing prophylactic wildcards destroys the utility of > the DNS-SD approach. Where in the draft is discussion of prophylactic wildcards? > An incongruity of mixing A-Labels with U-labels What state of affairs would cause you to mix A-labels and U-labels? U-labels are for display. A-labels are for lookup. > creates an unfriendly display of identifiers which > does not help limit the size of the list response. I don't understand this at all, but I think you may be conflating lookup and display contexts. This draft is not about UI elements, except insofar as the normal UI context constrain the way that lookups could be generated. > The > listing approach can be made safe with use of HTTP rather > than DNS, or at the least DNS over QUIC. You appear to be suggesting that we should be talking about a protocol other than DNS-SD. That's ok with me, but that's not what _this_ draft is about. I'll leave it to the chairs to determine whether discussion of such proposals is on charter for the WG. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 6 20:47:40 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096FF1A895B for ; Mon, 6 Jul 2015 20:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PrZDvn2K32SP for ; Mon, 6 Jul 2015 20:47:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4051A897E for ; Mon, 6 Jul 2015 20:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=630; q=dns/txt; s=iport; t=1436240800; x=1437450400; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=G/16Yim7FZDzeYRt1Kkjs+XP5G7uK/tTpanlOQ/8ckU=; b=gWUdaEugyYW6MRdKzBpTVjnh3gUI9tsrrMNfhcj/Y4x6VsEAy5kl2fRc gdtPdHaLGLW0tAT0krpx3zOBdd5yVbiJvkRQYNjhwC38mVGCjt3td8rOC uw+RsiVvFmu+xzSecVktPJDt4uAPCQGSVTyjrI3EBIrXBIHJ17MVo+BbW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BlAwAsSptV/4MNJK1cgxJUYAa9WQmBboc+OBQBAQEBAQEBgQqEKjo0HQE+QicEHIglDaMdpmMBAQEBBgEBAQEBARyPbhEBg2+BFAWUGAGLaIE6hBePK4NdJoN7bwGBDDqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,419,1432598400"; d="scan'208";a="7523948" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2015 03:46:39 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t673kdug006364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Jul 2015 03:46:39 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.109]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 22:46:39 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: WG last call on draft-ietf-dnssd-mdns-dns-interop-01 Thread-Index: AQHQuGeHLuddF6mW6Uq1LgQt1EI5VA== Date: Tue, 7 Jul 2015 03:46:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.40.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 03:47:40 -0000 Hi, This email begins a two week WGLC on draft-ietf-dnssd-mdns-dns-interop-01, = "On Interoperation of Labels Between mDNS and DNS". Tim and I believe the author has addressed the issues first brought forward= at IETF-92 and subsequently discussed on the WG mailing list.=20 You can see the draft here: http://www.ietf.org/id/draft-ietf-dnssd-mdns-dns-interop-01.txt Please send your comments or feedback to the list. The WGLC ends on July 20th (Monday). We will discuss/consider the result of the WGLC at the dnssd session at IET= F-93 in Prague, which is scheduled for 9AM Wednesday, July 22. - Ralph From nobody Tue Jul 7 05:51:16 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE131A01CB for ; Tue, 7 Jul 2015 05:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7sz6TrXcLADc for ; Tue, 7 Jul 2015 05:51:14 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5FE1A01BA for ; Tue, 7 Jul 2015 05:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1459; q=dns/txt; s=iport; t=1436273474; x=1437483074; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0PEzxLzlJhToJsPJmA4D9bjHMSccaI3c10zOmeip/Q8=; b=J5dKiNzVT97PA9S11C5JYO6o4EeWfN/0wzRV4seLgspFoFAQTspvfX91 P6aMVOVEizfZrp6Sr4J5YypCle1pEA4OntOikQXoTc7Rh6Zmuky80djhV vvJVxEW4E9WTdq373kTG9wn60XkGfdzbwGQmdKnPweTxpdBsO6iRIaHNR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B0AwCbyptV/5xdJa1cgxJUZr1lCYFvh0g4FAEBAQEBAQGBCoQqOlEBPkIPGASIQQ2kOqZXAQEBAQEBBAEBAQEBAQEBAQEBEwSTb4EUBYcFjRMBhGGHB4E6hBeTCSaDe4I2gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208";a="166316429" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 12:51:13 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t67CpD5R027753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Jul 2015 12:51:13 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.109]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 07:51:13 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Draft agenda Thread-Index: AQHQuLOaCfZTJZTEjUqz6G39tMRieg== Date: Tue, 7 Jul 2015 12:51:12 +0000 Message-ID: <442F34CA-A12A-488F-925F-A2993F2FD2E2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.118.95] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dnssd] Draft agenda X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 12:51:16 -0000 We've published a draft agenda for the upcoming dnssd WG meeting in Prague:= https://datatracker.ietf.org/meeting/93/agenda/dnssd and included below. Please let Tim or me know if you'd like to be given a slot on the agenda or= you have an additional topic that you'd like to see on the agenda. - Ralph dnssd WG Agenda - IETF 93 0900-1130CEST 2015-07-22 (Last revised 2015-07-01 17:18 ET) ---------------------------------- Administrivia Chown/Droms 10 minute= s =20 Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe On Interoperation of Labels Between mDNS and DNS Sullivan 30 minute= s draft-ietf-dnssd-mdns-dns-interop-00 Discussion of WG last call comments DNS Long-Lived Queries Pusateri/Cheshire 30 minute= s draft-ietf-dnssd-push-01 Review adoption as WG document based on new content Multicast DNS (mDNS) Threat Model and Security Consideration Rafiee 20 minute= s draft-rafiee-dnssd-mdns-threatmodel-01 Review of updates ----------= - 90 minute= s =20 From nobody Tue Jul 7 18:58:33 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E71B2D18 for ; Tue, 7 Jul 2015 18:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 R8p5Oy3Z8ZNh for ; Tue, 7 Jul 2015 18:58:28 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 B15621B2D16 for ; Tue, 7 Jul 2015 18:58:28 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so28988025obb.0 for ; Tue, 07 Jul 2015 18:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=TKEHPkwOGHmf29x3RTRFT97pTNx+zzI8pEdpsRFUDDA=; b=L/ZyhoW6gkl8ZO/BZ1E0kRm4UAzAX09VT5VTjdj3yJYerg+jMvdRKCSFcp/ksUJnko jlIYWHvR5ekTfui31xQCO2KjgGHTH0de8IUWz5m+z5tp0EPUz9Z5wOj0NyP45PVwUO9U XdFVLa4Im6bvbtwPQmh5dDBUwXVEv4pPTeNdHEw2AZvIRHpbWkL3L9ndaXtO89hjwrrb AlMrFoIaIxVOpor5ZJkZ56P48KgNKmJxfbMXfD7U6McdQu9uFp+abCQTvVlzEiEf9QaM KD1U7lIc/LoFvbf2xGbpUAw4+R+6yvV6l8d4fwltyGLj8OIYRQxrelGCJjWr/wpqRsm8 AaiQ== X-Received: by 10.60.76.35 with SMTP id h3mr6206758oew.46.1436320708254; Tue, 07 Jul 2015 18:58:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id f8sm438279obv.25.2015.07.07.18.58.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 18:58:27 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559C83C1.9070103@gmail.com> Date: Tue, 7 Jul 2015 18:58:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150707024239.GC52436@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 01:58:31 -0000 On 7/6/15 7:42 PM, Andrew Sullivan wrote: > On Mon, Jul 06, 2015 at 06:25:11PM -0700, Douglas Otis wrote: >> Why assume top level domains are always A-Labels? > Top level domains in the DNS are not always A-labels, because non-IDN > LDH labels are not A-labels. But any IDN that gets into the root > zone, at least as of any policy since 2003, will be an A-label. If > you have any evidence of any case where that is not what ICANN (in its > policy role) has instructed ICANN-IANA to do, I'd be interested to > hear of it. This draft did improve upon the first version, however the general statement made in section 4.3 third sentence: ,-- More important, operators of internationalized domain names will frequently publish such names in the DNS as A-labels; certainly, the top-most labels will always be A-labels. '-- Strike the always be A-Labels assertion and simply state top-most labels in the form of A-Labels are subject to the profile. This paragraph already states DNS-SD ought to query the portion of the Service Instance Name from global DNS and fall back to UTF-8 when needed. This provides global and IDNA-2008 preference. This is extremely important when attempting to mitigate DDoS and vulnerability concerns caused when local DNS-SD is given global access. Please don't consider this be automatically assumed. When dealing with locally defined names resolved using mDNS, these may not be stored or suitable for global DNS. See RFC6950 section 3.4 and 4. >> A scheme >> that visually conveys available services in list form for >> user selection is not well served with A-labels. > That's a user presentation issue, not a lookup issue. An application > ought, of course, to display such things as U-labels. U-labels and > A-labels are freely interconvertable (there's no such thing as a > U-label that does not have exactly one A-label). Do not express an expectation DNS-SD domains are to always appear in global DNS! >> Why not emphasize use of UTF-8 where possible to avoid >> rather messy conversion issues and resulting visual >> confusion. > To begin with, not every way of writing something using UTF-8 is a > U-label. Indeed, that's the _problem_ we're trying to deal with: mDNS > encourages labels that are not and never will be U-labels. Second, > you're never looking up a U-label, but an A-label; and this draft is > about how to make lookups work in resolution systems that have > different operational conventions. (Note that you could be looking up > a UTF-8 string that happens to match a U-label. And you could do that > in the DNS or you could do that in some other resolution system like > mDNS. If you try to do it in most -- I won't say "all" -- of the > high-level zones in the DNS, you will get NXDOMAIN if you get > anything.) Finally, the idea that somehow emphasising UTF-8 is going > to help in any way with conversion issues (messy or otherwise) or > visual confusion is more than a little preposterous. A far greater issue is created publishing DNS-SD in global DNS. Please see: https://www.kb.cert.org/vuls/id/550620 Having most of mDNS information return NXDOMAIN from global DNS is highly desired, and IMHO, should be required. >> 1) Dealing with look-alike spoofing can not depend upon >> registrar regulation or conversion rules. > No, indeed, it can't, at least where non-registration resolution > systems reside. It _can_ be ameliorated by registration rules > (i.e. operations policy) if those are sufficiently well-specified. > But there is absolutely no way, using DNS with IDNA or any other > technology, that look-alike spoofing is going to be prevented in every > case. And that is of course bound to be more challenging in a global > lookup context than in a link-local context, if only because one has > much more control in a link-local contest. Agreed. So why assume all DNS-SD can be globally published? Security concerns (spoofing, vulnerabilities, and DDoS issues) dictate a different view. >> 2) The size of a response accessed with a DNS wildcard may >> lead to DDoS issues. > What in the world does this have to do with any of it? This is true > when you're using DNS, regardless of whether there's a DNS-SD link. I > don't think we need to explore the possibility of DDoS every time the > magic string "DNS" appears in an Internet-Draft. These concerns should be raised when attempting a type of zero-config. Please see https://www.kb.cert.org/vuls/id/550620 >> Publishing prophylactic wildcards destroys the utility of >> the DNS-SD approach. > Where in the draft is discussion of prophylactic wildcards? Other than using RFC6950 private or split horizon, how else can DNS prevent excessive responses to Internet wildcard queries at a DNS-SD instance? >> An incongruity of mixing A-Labels with U-labels > What state of affairs would cause you to mix A-labels and U-labels? > U-labels are for display. A-labels are for lookup. Not using A-Labels can establish a locally resolvable namespace and user friendly displays. >> creates an unfriendly display of identifiers which >> does not help limit the size of the list response. > I don't understand this at all, but I think you may be conflating > lookup and display contexts. This draft is not about UI elements, > except insofar as the normal UI context constrain the way that lookups > could be generated. mDNS is based on the UI context directly supported by UTF-8 labels. As such, this document MUST consider more than mere conversion concerns. Inter-op should include related security considerations this draft wholly ignores when resolving. >> The >> listing approach can be made safe with use of HTTP rather >> than DNS, or at the least DNS over QUIC. > You appear to be suggesting that we should be talking about a protocol > other than DNS-SD. That's ok with me, but that's not what _this_ > draft is about. I'll leave it to the chairs to determine whether > discussion of such proposals is on charter for the WG. It seems DNS over QUIC can eliminate DDoS and IDNA-2008 issues while also improving Wifi operation sans a need for a proxy. Perhaps Apple might encourage Google to work on dprive after finishing WebRTC efforts. From a security standpoint, replacing Adobe Flash should have priority. In the meantime, ensure dnssd does not make matters worse. Regards, Douglas Otis From nobody Tue Jul 7 19:43:39 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BA31B2D65 for ; Tue, 7 Jul 2015 19:43:38 -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] autolearn=ham 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 Z73Qvgh2JE0o for ; Tue, 7 Jul 2015 19:43:36 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5561B2D63 for ; Tue, 7 Jul 2015 19:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 5E05710012 for ; Wed, 8 Jul 2015 02:43:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X8gsNtl43Un for ; Wed, 8 Jul 2015 02:43:33 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id 95B231000B for ; Wed, 8 Jul 2015 02:43:33 +0000 (UTC) Date: Tue, 7 Jul 2015 22:43:30 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150708024330.GA55186@mx2.yitter.info> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559C83C1.9070103@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 02:43:38 -0000 On Tue, Jul 07, 2015 at 06:58:25PM -0700, Douglas Otis wrote: > ,-- > More important, operators of internationalized domain names will > frequently publish such names in the DNS as A-labels; certainly, the > top-most labels will always be A-labels. > '-- > > Strike the always be A-Labels assertion and simply state top-most labels > in the form of A-Labels are subject to the profile. I think I don't understand your concern. Are you reading "the top-most labels will always be A-labels" to mean "every TLD is an A-label?" Do you mean this should say, "More important, operators of internationalized domain names will frequently publish such names in the DNS as A-labels, especially near the top level"? I'm not sure what it would mean to say "A-labels are subject to the profile." The profile is really a profile of the lowest common denominator labels that will work across various resolution technologies. So by definition they have to be. > This paragraph already states DNS-SD ought to query the portion > of the Service Instance Name from global DNS and fall back to UTF-8 when > needed. This provides global and IDNA-2008 preference. This is extremely > important when attempting to mitigate DDoS and vulnerability concerns > caused when local DNS-SD is given global access. Please don't consider > this be automatically assumed. I'm sorry; I don't understand this paragraph. What would you like to be different? > When dealing with locally defined names resolved using mDNS, these may not be > stored or suitable for global DNS. See RFC6950 section 3.4 and 4. Yes, I thought that was the point of the document. Is that not clear? > > >> A scheme > >> that visually conveys available services in list form for > >> user selection is not well served with A-labels. > > That's a user presentation issue, not a lookup issue. An application > > ought, of course, to display such things as U-labels. U-labels and > > A-labels are freely interconvertable (there's no such thing as a > > U-label that does not have exactly one A-label). > Do not express an expectation DNS-SD domains are to always > appear in global DNS! What is a DNS-SD domain? The _point_ of the document is that names used to look up DNS-SD records might appear in one of several different resolution systems. Obviously not every name need appear in all of them. The question is not where the name is, but rather what technologies are in use for undertaking resolution. I think this is made plain in the first section: Users of applications are, of course, frequently unconcerned with (not to say oblivious to) the name-resolution system(s) in service at any given moment, and are inclined simply to use the same domain names in different contexts. As a result, the same domain name might be tried using different name resolution technologies. If DNS-SD is to be used in an environment where multiple resolution systems (such as mDNS and DNS) are to be queried for services, then some parts of the domain names to be queried will need to be compatible with the rules and conventions for all the relevant technologies. Is that not clear? > A far greater issue is created publishing DNS-SD in global > DNS. Please see: > https://www.kb.cert.org/vuls/id/550620 You seem to be conflating mDNS with DNS-SD here. That link is not about publishing DNS-SD in the global DNS, but about responding to mDNS queries (i.e. responding from an mDNS responder) to a query from outside the link-local context. I don't think that's the same issue. > Having most of mDNS information return NXDOMAIN from global > DNS is highly desired, Surely mDNS just shouldn't respond from the DNS -- that is, an mDNS responder ought not to respond to queries on port 53. > Agreed. So why assume all DNS-SD can be globally > published? Security concerns (spoofing, > vulnerabilities, and DDoS issues) dictate a different view. I don't understand how that follows at all. DNS-SD is just a way of using certain SRV and TXT records to hold some data. The issue before us is what you do when one of the ways of publishing that data, and another of the ways, have different operational conventions controlling what data is allowed in the owner name. There is no controversy whatever that anything which could be queried and answered in mDNS can also be queried and answered in DNS. DNS is and always has used octets to make up its labels. mDNS uses exactly the same packet format. It has different operational conventions. The question is how to make such conventions consistent such that they can work together reliably. The issues you raise are not, as far as I can tell, directly relevant to that. > Other than using RFC6950 private or split horizon, how else > can DNS prevent excessive > responses to Internet wildcard queries at a DNS-SD instance? What is a DNS-SD instance? If you're running a DNS authoritative service, you have to be able to handle DNS operations. Why is this case special? > Not using A-Labels can establish a locally resolvable > namespace and user friendly displays. "User friendly displays" has nothing to do with this. I'm not entirely sure you have properly understood IDNA2008. Not using DNS can indeed establish a locally resolvable namespace, by (for instance) using a different resolution technology. > mDNS is based on the UI context directly supported by UTF-8 > labels. I disagree. mDNS uses the full repertoire of octets available in the DNS. DNS operators as a matter of fact (for various reasons explained elsewhere) use a subset of those octets. In user interfaces, since the latter is a subset of the former, the user interface considerations are non-existent (assuming the user interface understands IDNA). Certainly, if the user interface does not implement IDNA, we have a problem, but that has been a problem forever. I would have thought it obvious that such a user interface is not actually a case where one should expect the multi-resolution-form approach to work. Would a sentence to that effect help? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 8 00:48:49 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FC41B321A for ; Wed, 8 Jul 2015 00:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 pmveFh9upUBE for ; Wed, 8 Jul 2015 00:48:45 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 413911B3218 for ; Wed, 8 Jul 2015 00:48:45 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so33003542obb.0 for ; Wed, 08 Jul 2015 00:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=zSXQY4gkAM/sU8SOkWmgicKhvaQqGTkN1OYGmzXsF08=; b=pKOwumoUVrk6GxmIYk4N/RCGVSbItxiYvCzBjGOLh8EZcll9kWNDfzU8eK3GgbkgAx RgnLmql+I8JStccBoNUnlZuBCu6M+SC6rP/oSmPtP3lq77ECBt5diYeqAToTxXvGbFbB eiOQbUiyXmhAuOyUCumUx5htN36aEhMBz5b5dssdfNRcAJoz7wmZbZVzK8FggRDDGfHX PQizh565A0y1WAfW4uIzEeXsLgO/1uKrCno3iFM558Y466Nz4A2vC5zNmQpwIl2O+ESZ RzRWjAaUJ/pOmTf0cPPvV+ePLnSJkPnDcSpcpzIY15dviir6ZZj7k3vONlqMETKb189d isXw== X-Received: by 10.202.181.11 with SMTP id e11mr7890179oif.107.1436341724737; Wed, 08 Jul 2015 00:48:44 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id f3sm855463obm.18.2015.07.08.00.48.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 00:48:43 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559CD5D9.4030000@gmail.com> Date: Wed, 8 Jul 2015 00:48:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150708024330.GA55186@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 07:48:48 -0000 On 7/7/15 7:43 PM, Andrew Sullivan wrote: > On Tue, Jul 07, 2015 at 06:58:25PM -0700, Douglas Otis wrote: >> ,-- >> More important, operators of internationalized domain names will >> frequently publish such names in the DNS as A-labels; certainly, the >> top-most labels will always be A-labels. >> '-- >> >> Strike the always be A-Labels assertion and simply state top-most labels >> in the form of A-Labels are subject to the profile. > > I think I don't understand your concern. Are you reading "the > top-most labels will always be A-labels" to mean "every TLD is an > A-label?" Do you mean this should say, "More important, operators of > internationalized domain names will frequently publish such names in > the DNS as A-labels, especially near the top level"? No and no. Section 4.3 seems to conflate DNS as always meaning fully public global DNS. In the case of mDNS, this is likely not the case and this warrants great care in treating access having mixed DNS namespace resources. Was: More important, operators of internationalized domain names will frequently publish such names in the DNS as A-labels; certainly, the top-most labels will always be A-labels. Therefore, these labels will need to be subject to the profile. Change to: Operators of internationalized domain names frequently publish such names in the DNS as A-labels; these A-labels will be subject to the profile. Any namespace not included in the profile should be excluded from resolving in a global context. > I'm not sure what it would mean to say "A-labels are subject to the > profile." The profile is really a profile of the lowest common > denominator labels that will work across various resolution > technologies. So by definition they have to be. Rather than omitting an important consideration, state the need for global exclusions. >> This paragraph already states DNS-SD ought to query the portion >> of the Service Instance Name from global DNS and fall back to UTF-8 when >> needed. This provides global and IDNA-2008 preference. This is extremely >> important when attempting to mitigate DDoS and vulnerability concerns >> caused when local DNS-SD is given global access. Please don't consider >> this be automatically assumed. > > I'm sorry; I don't understand this paragraph. What would you like to > be different? > >> When dealing with locally defined names resolved using mDNS, these may not be >> stored or suitable for global DNS. See RFC6950 section 3.4 and 4. > > Yes, I thought that was the point of the document. Is that not clear? The point missed seems related to risks caused by not differentiating local and global namespaces as illustrated in the following examples. https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06#appendix-A https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06#appendix-B >> Do not express an expectation DNS-SD domains are to always >> appear in global DNS! > > What is a DNS-SD domain? The _point_ of the document is that names > used to look up DNS-SD records might appear in one of several > different resolution systems. Obviously not every name need appear in > all of them. The question is not where the name is, but rather what > technologies are in use for undertaking resolution. I think this is > made plain in the first section: > > Users of applications are, of course, frequently unconcerned with > (not to say oblivious to) the name-resolution system(s) in service at > any given moment, and are inclined simply to use the same domain > names in different contexts. As a result, the same domain name might > be tried using different name resolution technologies. If DNS-SD is > to be used in an environment where multiple resolution systems (such > as mDNS and DNS) are to be queried for services, then some parts of > the domain names to be queried will need to be compatible with the > rules and conventions for all the relevant technologies. > > Is that not clear? > >> A far greater issue is created publishing DNS-SD in global >> DNS. Please see: >> https://www.kb.cert.org/vuls/id/550620 > > You seem to be conflating mDNS with DNS-SD here. That link is not > about publishing DNS-SD in the global DNS, but about responding to > mDNS queries (i.e. responding from an mDNS responder) to a query from > outside the link-local context. I don't think that's the same issue. A DDoS risk occurs whenever RFC6763 DNS-SD resources are given Internet accessed from either mDNS or DNS servers. At least mDNS sets an upper limit for UDP responses to that of a jumbo frame, but both carry the same information and mDNS is unlikely to be accessible from the Internet. In that sense, DNS carries a much greater risk since it also supports RFC6891 EDNS(0). See RFC6763 Section 7.2. Granting brows-able access to DNS-SD resources using either mDNS or DNS resolvers allows a wildcard at an instance location to respond with as many as 839 separate and combined resources. Blocking wildcard use defeats its intended use, normally safe on a local network. >> Having most of mDNS information return NXDOMAIN from global >> DNS is highly desired, > > Surely mDNS just shouldn't respond from the DNS -- that is, an mDNS > responder ought not to respond to queries on port 53. It is not clear why mDNS resources moved to DNS via some automated scheme such as a mDNS to DNS proxy magically makes the transferred resources safe. There is risk whether Internet access is via port 5353 or port 53. >> Agreed. So why assume all DNS-SD can be globally >> published? Security concerns (spoofing, >> vulnerabilities, and DDoS issues) dictate a different view. > > I don't understand how that follows at all. DNS-SD is just a way of > using certain SRV and TXT records to hold some data. The issue before > us is what you do when one of the ways of publishing that data, and > another of the ways, have different operational conventions > controlling what data is allowed in the owner name. DNS-SD is structured differently. It combines a large number of sizable service RRsets below an Instance node. > There is no controversy whatever that anything which could be queried > and answered in mDNS can also be queried and answered in DNS. Labels do not afford operational protection from DDoS or vulnerability exposure whether defined as A-labels, U-labels or neither. mDNS is inherently safer because it normally is only accessible from the local network. An issue this draft continues to ignore, even when confronting a CERT notice! > DNS is > and always has used octets to make up its labels. mDNS uses exactly > the same packet format. It has different operational conventions. > The question is how to make such conventions consistent such that they > can work together reliably. The issues you raise are not, as far as I > can tell, directly relevant to that. That clearly states the problem we seem to be having. >> Other than using RFC6950 private or split horizon, how else >> can DNS prevent excessive >> responses to Internet wildcard queries at a DNS-SD instance? > > What is a DNS-SD instance? If you're running a DNS authoritative > service, you have to be able to handle DNS operations. Why is this > case special? DNS-SD describes a structure intended to be browsed and displayed having user friendly encoding. Had this been done using HTTP, DNS over QUIC or over SCTP there would be fewer issues. Nevertheless, there would still be issues. >> Not using A-Labels can establish a locally resolvable >> namespace and user friendly displays. > > "User friendly displays" has nothing to do with this. I'm not > entirely sure you have properly understood IDNA2008. Not using DNS > can indeed establish a locally resolvable namespace, by (for instance) > using a different resolution technology. Tools to browse DNS-SD DO NOT employ encoding used by IDNA2008, nor will users understand such results. The inter-op draft is attempting to define when such encoding is to be applied, but these actions are normally NEVER needed. Problems are created when attempting to mix local and global namespace while lacking essential heuristics. >> mDNS is based on the UI context directly supported by UTF-8 >> labels. > > I disagree. mDNS uses the full repertoire of octets available in the > DNS. DNS operators as a matter of fact (for various reasons explained > elsewhere) use a subset of those octets. DNS is able to use the SAME octets as used by mDNS. There might be cases where global DNS and local DNS wish to share a common zone for reasons likely related to use of certificates or minimizing servers. There seems little interest in establishing conversion rules between IDNA-global and DNS-SD/mDNS-local. As such, ensure terminology and methods don't blur the boundary between local and global namespaces. It seems a CNAME or DNAME convention might help at establishing a bridge or boundary between these two namespaces. > In user interfaces, since > the latter is a subset of the former, the user interface > considerations are non-existent (assuming the user interface > understands IDNA). Certainly, if the user interface does not > implement IDNA, we have a problem, but that has been a problem > forever. I would have thought it obvious that such a user interface is > not actually a case where one should expect the multi-resolution-form > approach to work. Would a sentence to that effect help? We see the problem differently. There is a real danger attempting to combine these two different namespaces, especially by encouraging the odd use of IDNA conversions except in clearly defined cases. IDNA or mDNS are not subsets of one or the other, nor should they be in my opinion. Regards, Douglas Otis From nobody Wed Jul 8 07:26:27 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D471B3723 for ; Wed, 8 Jul 2015 07:26:26 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_E-2nTbHaBQ for ; Wed, 8 Jul 2015 07:26:23 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 8508F1B36A3 for ; Wed, 8 Jul 2015 07:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 25B8510370 for ; Wed, 8 Jul 2015 14:20:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isG29J_p-6IV for ; Wed, 8 Jul 2015 14:20:04 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id BDE681000B for ; Wed, 8 Jul 2015 14:20:04 +0000 (UTC) Date: Wed, 8 Jul 2015 10:20:02 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150708142002.GE58386@mx2.yitter.info> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559CD5D9.4030000@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:26:26 -0000 On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: > > Section 4.3 seems to conflate DNS as always meaning fully > public global DNS. In the case of mDNS, this is likely not > the case I don't know what you mean by "conflate DNS as always meaning fully public global DNS". It is true _by definition_ that "the DNS" entails a single tree with a single root. It's certainly true that you can arrange things just right so that query-originators to you will see things that query-originators to other name servers will not see. But once you've put things in the DNS, any hope that you have that it will be private -- even in your split-brain arrangements -- are just wishful thinking. We have learned this over and over again, and I don't see why it ought to be controversial; I also don't know how it's relevant here. I also don't know what you mean by the second sentence here, since "in the case of mDNS" is by definition not the public global DNS -- it's a completely different protocol. > Change to: > Operators of internationalized domain names frequently > publish such names in the DNS as A-labels; these A-labels > will be subject to the profile. Any namespace not included > in the profile should be excluded from resolving in a global > context. As I said last time, I don't see what "these A-labels will be subject to the profile" adds and I find it confusing. Moreover, we _cannot_ rule out resolution in the DNS "from resolving in a global context". Here's an example of why. As Stuart has pointed out repeatedly, some enterprises already use DNS-SD in its "wide area" form -- that is, in the DNS. Such a name might have the following form: 3rd Floor Copier Printer.West Wing.example.com In a zone file, that is encoded as 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com The hex encoding of this to the wire format is left as an exercise, but the key point is that when you query (for instance) the example.com zone for that you send the entire owner name as the qname you're trying to look up. Your formulation would prohibit this, and we heard in previous meetings that the WG explicitly does _not_ want that, but instead wants a fallback to the DNS-SD (and for that matter non-IDNA) forms. I think, moreover, that anything that attempts to insist on formal backward incompatibility is doomed to failure. > Rather than omitting an important consideration, state the > need for global exclusions. But see above. There is not in fact such a need; rather, stating such a need would be false. > > The point missed seems related to risks caused by not > differentiating local and global namespaces as illustrated > in the following examples. You seem to think that there are "local" and "global" namespaces and we know which is which in advance. But we don't. That's _exactly_ the problem. If we knew that in advance, we would know which resolution system to use, and we would have no issue at all. > A DDoS risk occurs whenever RFC6763 DNS-SD resources are > given Internet accessed from either mDNS or DNS servers. There is no such thing as an mDNS server. I'm having an increasingly hard time understanding what you're talking about, and I'm decreasingly convinced that this is because of a fault in my own understanding. DDoS is a risk from large answers in the DNS; this is well known. I do not believe that this document is the place to attempt to discuss that in detail. To begin with, DNSOP is another WG. I see nothing wrong with writing a document from DNSOP saying, "Large answer sets present a danger to DNS operations," but I don't believe that one needs to repeat that advice in every single document anywhere that mentions the DNS. > See RFC6763 Section 7.2. Granting brows-able access to > DNS-SD resources using either mDNS or DNS resolvers allows a > wildcard at an instance location to respond with as many as > 839 separate and combined resources. Blocking wildcard use > defeats its intended use, normally safe on a local network. So, do you want the security considerations section to have a sentence that says, "Any use of the DNS that follows the outlines of this document necessarily incurs all DDoS risks resulting from the use of DNS"? I'm prepared to add that if you like. > It is not clear why mDNS resources moved to DNS I don't have any clue what that means. There are no "mDNS resources" that "move to DNS". Those are different protocols. > DNS-SD is structured differently. It combines a large > number of sizable service RRsets below an Instance node. Sure. It's a use of the DNS. You seem to be making an argument that DNS-SD is unsafe for use on the Internet, period. If that's your argument, then please publish "DNS-SD considered dangerous in the DNS" or something like that. This draft is about what you would do to make DNS-SD work predictably _assuming_ that you wanted to use more than one resolution mechanism, one of which is DNS, and I think including text about why DNS-SD is dangerous is going to be mighty confusing. If the WG concludes that DNS-SD is in fact dangerous for Internet use, then obviously this draft shouldn't be published at all because you shouldn't try to do any of these things in the first place. > Labels do not afford operational protection from DDoS or > vulnerability exposure whether defined as A-labels, U-labels > or neither. Yes. The current draft has nothing to do with DDoS risk from the use of the DNS, and I agree it is completely silent on that topic. I think that's a feature, but I'm willing to include the sentence noted above if that will help. > mDNS is inherently safer because it normally is > only accessible from the local network. An issue this draft > continues to ignore, even when confronting a CERT notice! Uh, the CERT notice you sent was complaining about mDNS _not_ being accessible only from the local network, which is what the problem was. That has absolutely nothing to do with DNS-anythingelse interoperation. > DNS-SD describes a structure intended to be browsed and > displayed having user friendly encoding. Wait. So your issue is that DNS-SD owner names are intended to be seen by humans? > Tools to browse DNS-SD DO NOT employ encoding used by > IDNA2008 Yes, which is why only the portion is treated as though it needs to be processed by IDNA. This is mostly because that's where the names will be in the DNS. The rest of the Service Instance Name continues to work according to the DNS-SD specification, and there are no mitigations of any sort about the possibly large number of names below the portion of a Service Instance Name. That's because we're using DNS-SD. > to be applied, but these actions are normally NEVER needed. The point of the draft, which I think is explained pretty clearly in the introduction, is that you'll need the IDNA processing for the portion or else DNS will just return RCODE 3 and you won't find what you're looking for. > > I disagree. mDNS uses the full repertoire of octets available in the > > DNS. DNS operators as a matter of fact (for various reasons explained > > elsewhere) use a subset of those octets. > > DNS is able to use the SAME octets as used by mDNS. Yes, which is entirely consistent with what I said. > There > might be cases where global DNS and local DNS wish to share > a common zone for reasons likely related to use of > certificates or minimizing servers. What exactly is "local DNS"? > We see the problem differently. There is a real danger > attempting to combine these two different namespaces, I think what you're saying is that the goal of the draft is dangerous and bad. That's ok with me, but it seems really to be an argument that the WG shouldn't try to do what it is chartered to do, no? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 8 19:38:00 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D221A8A03 for ; Wed, 8 Jul 2015 19:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 48vwcUu0c7Qo for ; Wed, 8 Jul 2015 19:37:55 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 3D19D1A8A01 for ; Wed, 8 Jul 2015 19:37:55 -0700 (PDT) Received: by oiab3 with SMTP id b3so61760594oia.1 for ; Wed, 08 Jul 2015 19:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=0g2t33HaTkNxDuBSgCeLjK2uWFwNTJp9G6VQd+OFtKs=; b=CRJAlPmd8n/FMRedSxFQm+7F3NIvpb+VW8gApqJwzgC1xms2YmyRPY3RMV7MYKfaGJ T1hJQUj4rp8dSSWxXvsmYRDK967SUPVcfprL7n/jWpi+AjBRm2FXfSPlVYOssI2o9Q0M C5O+wIYP2TxPTh6BJx92Nutam+qyxdLvWxFeB7bwD14HJYNMXZo+FORwPSsEVVcfimrY 8Wl366arom61rHQwo3chl6llP1qWv7hrap+eRIZnKbwwnMjjDgG2qwZb/v9PHjBPRD/V wdy6Ypte/HCQzJWhnU625YHCjPp/jhc7/SLLnpIQ26pdv/6otCTpHQKW9oB+HEI+M0bb 7JLw== X-Received: by 10.182.165.71 with SMTP id yw7mr12380961obb.16.1436409474745; Wed, 08 Jul 2015 19:37:54 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id c3sm2453211obo.5.2015.07.08.19.37.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 19:37:53 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559DDE7E.7050201@gmail.com> Date: Wed, 8 Jul 2015 19:37:50 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150708142002.GE58386@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 02:37:58 -0000 On 7/8/15 7:20 AM, Andrew Sullivan wrote: > On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: >> >> Section 4.3 seems to conflate DNS as always meaning fully >> public global DNS. In the case of mDNS, this is likely not >> the case > > I don't know what you mean by "conflate DNS as always meaning fully > public global DNS". It is true _by definition_ that "the DNS" entails > a single tree with a single root. It's certainly true that you can > arrange things just right so that query-originators to you will see > things that query-originators to other name servers will not see. But > once you've put things in the DNS, any hope that you have that it will > be private -- even in your split-brain arrangements -- are just > wishful thinking. We have learned this over and over again, and I > don't see why it ought to be controversial; I also don't know how it's > relevant here. Dear Andrew, Many indicated in some environments there is a need to avoid excessive multicast traffic when it negatively impacts wireless networks. To avoid resources being resolved using mDNS multicast, a different TLD other than .local is needed. The draft-ietf-dnssd-hybrid-00 proxy scheme offered a fairly automated method for moving mDNS resources into DNS which could use an Ambiguous Local Qualified Domain Name (ALQDN) space, such as .home as suggested by the draft, or even a domain expressed using UTF-8 label locally recognized (not encoded and without the 'xn--' prefix). Since often these resources are not suitable for the Internet, a heuristic to identify zones to be filtered from Internet responses based on a "Profile" seems like a viable solution. Establishing a "Profile" offering heuristics to identify suitable global resources makes sense since different services normally support local mDNS based resolution which ignore IDNA. IMHO, a strategy to globally browse DNS using massive responses should be generally discouraged until the underlying transport offers effective congestion mitigation. DNS amplification leading to DDoS still persists largely due to insufficient ingress filtering compliance with BCP38 one and a half decades later. That said, DNS-SD may even place a campus having just a few compromised systems at risk. > I also don't know what you mean by the second sentence here, since "in > the case of mDNS" is by definition not the public global DNS -- it's a > completely different protocol. Except when mDNS resources are automatically transferred to DNS. mDNS is even able to cache DNS resources. >> Change to: >> Operators of internationalized domain names frequently >> publish such names in the DNS as A-labels; these A-labels >> will be subject to the profile. Any namespace not included >> in the profile should be excluded from resolving in a global >> context. > > As I said last time, I don't see what "these A-labels will be subject > to the profile" adds and I find it confusing. Moreover, we _cannot_ > rule out resolution in the DNS "from resolving in a global context". > Here's an example of why. > > As Stuart has pointed out repeatedly, some enterprises already use > DNS-SD in its "wide area" form -- that is, in the DNS. Such a name > might have the following form: > > 3rd Floor Copier Printer.West Wing.example.com > > In a zone file, that is encoded as > > 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com Allowing limited and administrated exceptions is part of the dnssd requirement document. That said, it is dangerous to tamper with domains having UTF-8 TLD labels and assume these resources can be exposed to the Internet. Failing to resolve when using non-local tools would be a desired feature. > The hex encoding of this to the wire format is left as an exercise, > but the key point is that when you query (for instance) the > example.com zone for that you send the entire owner name as the qname > you're trying to look up. Your formulation would prohibit this, and > we heard in previous meetings that the WG explicitly does _not_ want > that, but instead wants a fallback to the DNS-SD (and for that matter > non-IDNA) forms. I think, moreover, that anything that attempts to > insist on formal backward incompatibility is doomed to failure. Not disagreeing. A-Labels can support a heuristic able to identify global resources. Wasn't that the purpose of your "profile"? Determining when conversions are appropriate? >> Rather than omitting an important consideration, state the >> need for global exclusions. > > But see above. There is not in fact such a need; rather, stating such > a need would be false. Are you suggesting all locally defined TLDs contained in DNS (even when it is able to isolate locally defined TLDs such as .home) must always be encoded per IDNA? If properly identified by a Profile, the Internet should never see these resources. Such a strategy should allow desired multicast avoidance (such as not using .local. ) without otherwise changing local namespace handling routines as used with mDNS. >> The point missed seems related to risks caused by not >> differentiating local and global namespaces as illustrated >> in the following examples. > > You seem to think that there are "local" and "global" namespaces and > we know which is which in advance. But we don't. That's _exactly_ > the problem. If we knew that in advance, we would know which > resolution system to use, and we would have no issue at all. A profile should also establish the labels accessible only using local resolution tools. Use of '_' already carves out encoding exceptions for hosts and instances label. Why not carve out entire local zones that are to be excluded from various resolvers and interfaces? >> A DDoS risk occurs whenever RFC6763 DNS-SD resources are >> given Internet accessed from either mDNS or DNS servers. > > There is no such thing as an mDNS server. IMHO, an mDNS node acts as its own server when conveying its resources. > I'm having an increasingly > hard time understanding what you're talking about, and I'm > decreasingly convinced that this is because of a fault in my own > understanding. DDoS is a risk from large answers in the DNS; this is > well known. I do not believe that this document is the place to > attempt to discuss that in detail. To begin with, DNSOP is another > WG. I see nothing wrong with writing a document from DNSOP saying, > "Large answer sets present a danger to DNS operations," but I don't > believe that one needs to repeat that advice in every single document > anywhere that mentions the DNS. The situation is serious but not fatal if caution were to prevail. >> See RFC6763 Section 7.2. Granting brows-able access to >> DNS-SD resources using either mDNS or DNS resolvers allows a >> wildcard at an instance location to respond with as many as >> 839 separate and combined resources. Blocking wildcard use >> defeats its intended use, normally safe on a local network. > > So, do you want the security considerations section to have a sentence > that says, "Any use of the DNS that follows the outlines of this > document necessarily incurs all DDoS risks resulting from the use of > DNS"? I'm prepared to add that if you like. It seems it would be more constructive as part of a comprehensive strategy. >> It is not clear why mDNS resources moved to DNS > > I don't have any clue what that means. There are no "mDNS resources" > that "move to DNS". Those are different protocols. > >> DNS-SD is structured differently. It combines a large >> number of sizable service RRsets below an Instance node. > > Sure. It's a use of the DNS. You seem to be making an argument that > DNS-SD is unsafe for use on the Internet, period. Don't ignore issues the hybrid scheme attempts to solve (with the aid of careful administration in specific cases to reduce the risk). Risks demand either clearly defined prohibitions against local UTF-8 namespace in DNS (which seems unlikely) or properly identified handling profiles, which should be the purpose of this document. > If that's your > argument, then please publish "DNS-SD considered dangerous in the DNS" > or something like that. This draft is about what you would do to make > DNS-SD work predictably _assuming_ that you wanted to use more than > one resolution mechanism, one of which is DNS, and I think including > text about why DNS-SD is dangerous is going to be mighty confusing. > If the WG concludes that DNS-SD is in fact dangerous for Internet use, > then obviously this draft shouldn't be published at all because you > shouldn't try to do any of these things in the first place. Thanks for the encouragement. I have discussed various solutions with others having extensive DNS knowledge. Any general solution will likely arrive too late to avoid sizable problems that could occur when needlessly exposing DNS-SD resources to the Internet. Allowing a few administratively managed exceptions should be fine and keeping within the dnssd requirements. >> Labels do not afford operational protection from DDoS or >> vulnerability exposure whether defined as A-labels, U-labels >> or neither. > > Yes. The current draft has nothing to do with DDoS risk from the use > of the DNS, and I agree it is completely silent on that topic. I > think that's a feature, but I'm willing to include the sentence noted > above if that will help. Perhaps you can see where this might be headed. Something along the lines of a profile exclusion of local resources, to facilitate the conveying of these resources to only local resolver tools that understand the specific needed conversions and the scope of their access. A strategy mimicking what is currently based on mDNS. >> mDNS is inherently safer because it normally is >> only accessible from the local network. An issue this draft >> continues to ignore, even when confronting a CERT notice! > > Uh, the CERT notice you sent was complaining about mDNS _not_ being > accessible only from the local network, which is what the problem was. > That has absolutely nothing to do with DNS-anythingelse > interoperation. Review researcher's notes at: https://github.com/chadillac/mdns_recon The concerns relate specifically to access granted to mDNS resources. Unfettered access may create a rather bleak situation that can be salvaged by administratively placing only key resources into non-local zones. (i.e. not in a default .home or its multilingual equivalent.) Appendix notes found in http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 previously noted on this mailing-lists about 6 months prior further supports these findings. >> DNS-SD describes a structure intended to be browsed and >> displayed having user friendly encoding. > > Wait. So your issue is that DNS-SD owner names are intended to be > seen by humans? Clearly an issue whenever IDNA encoding is imposed on exclusively local resources where user interfaces don't support their conversion. >> Tools to browse DNS-SD DO NOT employ encoding used by >> IDNA2008 > > Yes, which is why only the portion is treated as though it > needs to be processed by IDNA. This is mostly because that's where > the names will be in the DNS. The rest of the Service Instance Name > continues to work according to the DNS-SD specification, and there are > no mitigations of any sort about the possibly large number of names > below the portion of a Service Instance Name. That's because > we're using DNS-SD. Which is why there should be a strategy to restrict global access to just resources that are administratively permitted. >> to be applied, but these actions are normally NEVER needed. > > The point of the draft, which I think is explained pretty clearly in > the introduction, is that you'll need the IDNA processing for the > portion or else DNS will just return RCODE 3 and you won't > find what you're looking for. > >>> I disagree. mDNS uses the full repertoire of octets available in the >>> DNS. DNS operators as a matter of fact (for various reasons explained >>> elsewhere) use a subset of those octets. >> >> DNS is able to use the SAME octets as used by mDNS. > > Yes, which is entirely consistent with what I said. > >> There >> might be cases where global DNS and local DNS wish to share >> a common zone for reasons likely related to use of >> certificates or minimizing servers. > > What exactly is "local DNS"? This might employ a split horizon server excluding interface and resolver access from specifically "profiled" zones. >> We see the problem differently. There is a real danger >> attempting to combine these two different namespaces, > > I think what you're saying is that the goal of the draft is dangerous > and bad. That's ok with me, but it seems really to be an argument > that the WG shouldn't try to do what it is chartered to do, no? This and the poor track record for BCP38 should motivate DNS transport improvements in the long run. In the meantime, not aggressively globally deploying DNS-SD should be an appropriate and conservative strategy. Regards, Douglas Otis From nobody Fri Jul 10 16:31:49 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DD1A1A04 for ; Fri, 10 Jul 2015 16:31:46 -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] autolearn=ham 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 H5RJ9liL1nhf for ; Fri, 10 Jul 2015 16:31:43 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4041A19F2 for ; Fri, 10 Jul 2015 16:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id CCA13105DB; Fri, 10 Jul 2015 23:31:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzkg2ybuWDZA; Fri, 10 Jul 2015 23:31:41 +0000 (UTC) Received: from [10.10.228.112] (mobile-107-107-60-253.mycingular.net [107.107.60.253]) by mx2.yitter.info (Postfix) with ESMTPSA id 2F7F8105DC; Fri, 10 Jul 2015 23:31:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Andrew Sullivan X-Mailer: iPhone Mail (12H143) In-Reply-To: <559DDE7E.7050201@gmail.com> Date: Fri, 10 Jul 2015 19:31:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <559DDE7E.7050201@gmail.com> To: Douglas Otis Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 23:31:46 -0000 Hi Doug, Apologies for the iphoney top post. I note that the Prague agenda has fully 3= 0 minutes for this discussion, but if we spend all of it trying to understan= d vocabulary you seem to be introducing we're not going to be successful. Do= you think you could create a glossary of some of these terms, or write an e= mail outlining some of the spaces you have in mind or something? I get the i= mpression you have a vision of the name space different to mine, and I'm jus= t not understanding you.=20 Thanks, A --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On Jul 8, 2015, at 22:37, Douglas Otis wrote: >=20 >=20 >=20 >> On 7/8/15 7:20 AM, Andrew Sullivan wrote: >>> On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: >>>=20 >>> Section 4.3 seems to conflate DNS as always meaning fully >>> public global DNS. In the case of mDNS, this is likely not >>> the case >>=20 >> I don't know what you mean by "conflate DNS as always meaning fully >> public global DNS". It is true _by definition_ that "the DNS" entails >> a single tree with a single root. It's certainly true that you can >> arrange things just right so that query-originators to you will see >> things that query-originators to other name servers will not see. But >> once you've put things in the DNS, any hope that you have that it will >> be private -- even in your split-brain arrangements -- are just >> wishful thinking. We have learned this over and over again, and I >> don't see why it ought to be controversial; I also don't know how it's >> relevant here. >=20 > Dear Andrew, >=20 > Many indicated in some environments there is a need to avoid > excessive multicast traffic when it negatively impacts > wireless networks. To avoid resources being resolved using > mDNS multicast, a different TLD other than .local is needed. > The draft-ietf-dnssd-hybrid-00 proxy scheme offered a > fairly automated method for moving mDNS resources into DNS > which could use an Ambiguous Local Qualified Domain Name > (ALQDN) space, such as .home as suggested by the draft, or > even a domain expressed using UTF-8 label locally recognized > (not encoded and without the 'xn--' prefix). Since often > these resources are not suitable for the Internet, a > heuristic to identify zones to be filtered from Internet > responses based on a "Profile" seems like a viable solution. >=20 > Establishing a "Profile" offering heuristics to identify > suitable global resources makes sense since different > services normally support local mDNS based resolution which > ignore IDNA. IMHO, a strategy to globally browse DNS using > massive responses should be generally discouraged until the > underlying transport offers effective congestion mitigation. > DNS amplification leading to DDoS still persists largely > due to insufficient ingress filtering compliance with BCP38 > one and a half decades later. That said, DNS-SD may even > place a campus having just a few compromised systems at risk. >=20 >> I also don't know what you mean by the second sentence here, since "in >> the case of mDNS" is by definition not the public global DNS -- it's a >> completely different protocol. >=20 > Except when mDNS resources are automatically transferred to > DNS. mDNS is even able to cache DNS resources. >=20 >>> Change to: >>> Operators of internationalized domain names frequently >>> publish such names in the DNS as A-labels; these A-labels >>> will be subject to the profile. Any namespace not included >>> in the profile should be excluded from resolving in a global >>> context. >>=20 >> As I said last time, I don't see what "these A-labels will be subject >> to the profile" adds and I find it confusing. Moreover, we _cannot_ >> rule out resolution in the DNS "from resolving in a global context". >> Here's an example of why. >>=20 >> As Stuart has pointed out repeatedly, some enterprises already use >> DNS-SD in its "wide area" form -- that is, in the DNS. Such a name >> might have the following form: >>=20 >> 3rd Floor Copier Printer.West Wing.example.com >>=20 >> In a zone file, that is encoded as >>=20 >> 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com >=20 > Allowing limited and administrated exceptions is part of the > dnssd requirement document. That said, it is dangerous to > tamper with domains having UTF-8 TLD labels and assume these > resources can be exposed to the Internet. Failing to > resolve when using non-local tools would be a desired feature. >=20 >> The hex encoding of this to the wire format is left as an exercise, >> but the key point is that when you query (for instance) the >> example.com zone for that you send the entire owner name as the qname >> you're trying to look up. Your formulation would prohibit this, and >> we heard in previous meetings that the WG explicitly does _not_ want >> that, but instead wants a fallback to the DNS-SD (and for that matter >> non-IDNA) forms. I think, moreover, that anything that attempts to >> insist on formal backward incompatibility is doomed to failure. >=20 > Not disagreeing. A-Labels can support a heuristic able to > identify global resources. Wasn't that the purpose of your > "profile"? Determining when conversions are appropriate? >=20 >>> Rather than omitting an important consideration, state the >>> need for global exclusions. >>=20 >> But see above. There is not in fact such a need; rather, stating such >> a need would be false. >=20 > Are you suggesting all locally defined TLDs contained in DNS > (even when it is able to isolate locally defined TLDs such > as .home) must always be encoded per IDNA? If properly > identified by a Profile, the Internet should never see these > resources. Such a strategy should allow desired multicast > avoidance (such as not using .local. ) without otherwise > changing local namespace handling routines as used with mDNS. >=20 >>> The point missed seems related to risks caused by not >>> differentiating local and global namespaces as illustrated >>> in the following examples. >>=20 >> You seem to think that there are "local" and "global" namespaces and >> we know which is which in advance. But we don't. That's _exactly_ >> the problem. If we knew that in advance, we would know which >> resolution system to use, and we would have no issue at all. >=20 > A profile should also establish the labels accessible only > using local resolution tools. Use of '_' already carves out > encoding exceptions for hosts and instances label. Why not > carve out entire local zones that are to be excluded from > various resolvers and interfaces? >=20 >>> A DDoS risk occurs whenever RFC6763 DNS-SD resources are >>> given Internet accessed from either mDNS or DNS servers. >>=20 >> There is no such thing as an mDNS server. >=20 > IMHO, an mDNS node acts as its own server when conveying its > resources. >=20 >> I'm having an increasingly >> hard time understanding what you're talking about, and I'm >> decreasingly convinced that this is because of a fault in my own >> understanding. DDoS is a risk from large answers in the DNS; this is >> well known. I do not believe that this document is the place to >> attempt to discuss that in detail. To begin with, DNSOP is another >> WG. I see nothing wrong with writing a document from DNSOP saying, >> "Large answer sets present a danger to DNS operations," but I don't >> believe that one needs to repeat that advice in every single document >> anywhere that mentions the DNS. >=20 > The situation is serious but not fatal if caution were to > prevail. >=20 >>> See RFC6763 Section 7.2. Granting brows-able access to >>> DNS-SD resources using either mDNS or DNS resolvers allows a >>> wildcard at an instance location to respond with as many as >>> 839 separate and combined resources. Blocking wildcard use >>> defeats its intended use, normally safe on a local network. >>=20 >> So, do you want the security considerations section to have a sentence >> that says, "Any use of the DNS that follows the outlines of this >> document necessarily incurs all DDoS risks resulting from the use of >> DNS"? I'm prepared to add that if you like. >=20 > It seems it would be more constructive as part of a > comprehensive strategy. >=20 >>> It is not clear why mDNS resources moved to DNS >>=20 >> I don't have any clue what that means. There are no "mDNS resources" >> that "move to DNS". Those are different protocols. >>=20 >>> DNS-SD is structured differently. It combines a large >>> number of sizable service RRsets below an Instance node. >>=20 >> Sure. It's a use of the DNS. You seem to be making an argument that >> DNS-SD is unsafe for use on the Internet, period. >=20 > Don't ignore issues the hybrid scheme attempts to solve > (with the aid of careful administration in specific cases to > reduce the risk). Risks demand either clearly defined > prohibitions against local UTF-8 namespace in DNS (which > seems unlikely) or properly identified handling profiles, > which should be the purpose of this document. >=20 >> If that's your >> argument, then please publish "DNS-SD considered dangerous in the DNS" >> or something like that. This draft is about what you would do to make >> DNS-SD work predictably _assuming_ that you wanted to use more than >> one resolution mechanism, one of which is DNS, and I think including >> text about why DNS-SD is dangerous is going to be mighty confusing. >> If the WG concludes that DNS-SD is in fact dangerous for Internet use, >> then obviously this draft shouldn't be published at all because you >> shouldn't try to do any of these things in the first place. >=20 > Thanks for the encouragement. I have discussed various > solutions with others having extensive DNS knowledge. Any > general solution will likely arrive too late to avoid > sizable problems that could occur when needlessly exposing > DNS-SD resources to the Internet. Allowing a few > administratively managed exceptions should be fine and > keeping within the dnssd requirements. >=20 >>> Labels do not afford operational protection from DDoS or >>> vulnerability exposure whether defined as A-labels, U-labels >>> or neither. >>=20 >> Yes. The current draft has nothing to do with DDoS risk from the use >> of the DNS, and I agree it is completely silent on that topic. I >> think that's a feature, but I'm willing to include the sentence noted >> above if that will help. >=20 > Perhaps you can see where this might be headed. Something > along the lines of a profile exclusion of local resources, > to facilitate the conveying of these resources to only local > resolver tools that understand the specific needed > conversions and the scope of their access. A strategy > mimicking what is currently based on mDNS. >=20 >>> mDNS is inherently safer because it normally is >>> only accessible from the local network. An issue this draft >>> continues to ignore, even when confronting a CERT notice! >>=20 >> Uh, the CERT notice you sent was complaining about mDNS _not_ being >> accessible only from the local network, which is what the problem was. >> That has absolutely nothing to do with DNS-anythingelse >> interoperation. >=20 > Review researcher's notes at: > https://github.com/chadillac/mdns_recon >=20 > The concerns relate specifically to access granted to mDNS > resources. Unfettered access may create a rather bleak > situation that can be salvaged by administratively placing > only key resources into non-local zones. (i.e. not in a > default .home or its multilingual equivalent.) >=20 > Appendix notes found in > http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 > previously noted on this mailing-lists about 6 months prior > further supports these findings. >=20 >>> DNS-SD describes a structure intended to be browsed and >>> displayed having user friendly encoding. >>=20 >> Wait. So your issue is that DNS-SD owner names are intended to be >> seen by humans? >=20 > Clearly an issue whenever IDNA encoding is imposed on > exclusively local resources where user interfaces don't > support their conversion. >=20 >>> Tools to browse DNS-SD DO NOT employ encoding used by >>> IDNA2008 >>=20 >> Yes, which is why only the portion is treated as though it >> needs to be processed by IDNA. This is mostly because that's where >> the names will be in the DNS. The rest of the Service Instance Name >> continues to work according to the DNS-SD specification, and there are >> no mitigations of any sort about the possibly large number of names >> below the portion of a Service Instance Name. That's because >> we're using DNS-SD. >=20 > Which is why there should be a strategy to restrict global > access to just resources that are administratively permitted. >=20 >>> to be applied, but these actions are normally NEVER needed. >>=20 >> The point of the draft, which I think is explained pretty clearly in >> the introduction, is that you'll need the IDNA processing for the >> portion or else DNS will just return RCODE 3 and you won't >> find what you're looking for. >>=20 >>>> I disagree. mDNS uses the full repertoire of octets available in the >>>> DNS. DNS operators as a matter of fact (for various reasons explained >>>> elsewhere) use a subset of those octets. >>>=20 >>> DNS is able to use the SAME octets as used by mDNS. >>=20 >> Yes, which is entirely consistent with what I said. =20 >>=20 >>> There >>> might be cases where global DNS and local DNS wish to share >>> a common zone for reasons likely related to use of >>> certificates or minimizing servers. >>=20 >> What exactly is "local DNS"? >=20 > This might employ a split horizon server excluding interface > and resolver access from specifically "profiled" zones. >=20 >>> We see the problem differently. There is a real danger >>> attempting to combine these two different namespaces, >>=20 >> I think what you're saying is that the goal of the draft is dangerous >> and bad. That's ok with me, but it seems really to be an argument >> that the WG shouldn't try to do what it is chartered to do, no? >=20 > This and the poor track record for BCP38 should motivate DNS > transport improvements in the long run. In the meantime, > not aggressively globally deploying DNS-SD should be an > appropriate and conservative strategy. >=20 > Regards, > Douglas Otis >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Jul 14 22:50:59 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474361A6F87; Tue, 14 Jul 2015 22:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 EADzn8hd8d1h; Tue, 14 Jul 2015 22:50:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A66F71A6F5D; Tue, 14 Jul 2015 22:50:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BAE85180205; Tue, 14 Jul 2015 22:47:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150715054723.BAE85180205@rfc-editor.org> Date: Tue, 14 Jul 2015 22:47:23 -0700 (PDT) Archived-At: Cc: dnssd@ietf.org, rfc-editor@rfc-editor.org Subject: [dnssd] RFC 7558 on Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 05:50:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7558 Title: Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions Author: K. Lynn, S. Cheshire, M. Blanchet, D. Migault Status: Informational Stream: IETF Date: July 2015 Mailbox: kerry.lynn@verizon.com, cheshire@apple.com, Marc.Blanchet@viagenie.ca, daniel.migault@ericsson.com Pages: 14 Characters: 30291 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnssd-requirements-06.txt URL: https://www.rfc-editor.org/info/rfc7558 DOI: http://dx.doi.org/10.17487/RFC7558 DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD. This document is a product of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jul 15 07:29:00 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933B81AC3B2 for ; Wed, 15 Jul 2015 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 A_BSpUXlcpUD for ; Wed, 15 Jul 2015 07:28:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83FD1AC3AE for ; Wed, 15 Jul 2015 07:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1436970536; x=1438180136; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SmQ2r88zLgSlx4EOc5vufXrfhqrM2tciqsTirY+ScIc=; b=PiSBMYlry0C7KoTmzCmjClbhOLEDnRpTpnaBeyuh+0NfvzvJRkl9/dde w1Z6i5dH3w7ZP1pVh7CBaHM7SWgLMy6qrixngjDq1828EExJi0S5i++ZN 95cEjFfczw/L2QKEa1SdrSTD+EfkzcEYRfdjDcUegXxkZLdUspcyd4Q3P 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtAwDgbaZV/5xdJa1bgxNUaQaHRbQDCYF2hXcCgTg4FAEBAQEBAQGBCoQjAQEBAwEdHTQQCwIBCBgeEDIlAgQTCYgdCA3QcQEBAQEBAQEBAQEBAQEBAQEBAQEZi0yEIxEBHjqDF4EUBZQ9AYwNgUCEGI89g2Emg3xvAYEMOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="168827571" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 15 Jul 2015 14:28:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6FESrhn000966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Jul 2015 14:28:53 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.109]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 09:28:52 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: WG last call on draft-ietf-dnssd-mdns-dns-interop-01 Thread-Index: AQHQuGeHKQgHqs5Y+02X6aZEJ1Ux5Z3c7XEA Date: Wed, 15 Jul 2015 14:28:52 +0000 Message-ID: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.118.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:28:58 -0000 Reminder - the WG last call for draft-ietf-dnssd-mdns-dns-interop is in pro= gress and we will discuss any last call comments during the WG meeting in P= rague. - Ralph > On Jul 6, 2015, at 11:46 PM 7/6/15, Ralph Droms (rdroms) wrote: >=20 > Hi, >=20 > This email begins a two week WGLC on draft-ietf-dnssd-mdns-dns-interop-01= , "On Interoperation of Labels Between mDNS and DNS". >=20 > Tim and I believe the author has addressed the issues first brought forwa= rd at IETF-92 and subsequently discussed on the WG mailing list.=20 >=20 > You can see the draft here: > http://www.ietf.org/id/draft-ietf-dnssd-mdns-dns-interop-01.txt >=20 > Please send your comments or feedback to the list. >=20 > The WGLC ends on July 20th (Monday). >=20 > We will discuss/consider the result of the WGLC at the dnssd session at I= ETF-93 in Prague, which is scheduled for 9AM Wednesday, July 22. >=20 > - Ralph >=20 From nobody Fri Jul 17 06:40:08 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278171B33E2 for ; Fri, 17 Jul 2015 06:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ENkh-EdM9q7q for ; Fri, 17 Jul 2015 06:40:07 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FF21B33D9 for ; Fri, 17 Jul 2015 06:40:06 -0700 (PDT) Received: by qgep37 with SMTP id p37so47011800qge.1 for ; Fri, 17 Jul 2015 06:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=LDZ1Cg8cKvfFXMLL3K8jDXDflojiqj9rOeuKTq/fnTs=; b=UCJsfOU6jx6BeF8FhM8Vwt9SZ9dWKO2rnIqi4bB0Nf9M99PMt0oyxbtKJdZnoOYRma MjttbGAZ23Bgi3p42q0QopdVpbAm3+4hKckTh2QDDUy+vMpfGbFJPR3Oi9wOrZusod/c FukqiBSrQ8NH1C0MR/WlrkAgjRgoCkQbUVxlv+wg1d994lGxkMFfh5+ye6cF9IAzfU0N mgSaNoOfwZMFGFl4HHUMOf5qiGa/e+QOfodMbptDML/5IKZv0lWD8b3SGJcOVYkqINVa R18Yz6+T0NrWSEimCRd2rb6q3Hj9/OXl3zynXi2HpwvVSes4stSrFol4nojZZq206+xb foFw== X-Received: by 10.140.150.211 with SMTP id 202mr19602541qhw.42.1437140406024; Fri, 17 Jul 2015 06:40:06 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1003::358? ([2001:420:c0c4:1003::358]) by smtp.gmail.com with ESMTPSA id d10sm5837244qhc.9.2015.07.17.06.40.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jul 2015 06:40:05 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <593A82F1-49C2-4A17-9A1B-1FD22E438A51@gmail.com> Date: Fri, 17 Jul 2015 15:40:02 +0200 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [dnssd] Upcoming meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 13:40:08 -0000 We're looking for a note-taker and a jabber scribe for our upcoming WG = meeting. - Ralph From nobody Fri Jul 17 09:27:13 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FDE1A889C for ; Fri, 17 Jul 2015 09:27: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] autolearn=ham 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 HhxTxkllKgEc for ; Fri, 17 Jul 2015 09:27:08 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7661A8840 for ; Fri, 17 Jul 2015 09:27:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id DDF711000B for ; Fri, 17 Jul 2015 16:27:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJoNTyIhGnnq for ; Fri, 17 Jul 2015 16:27:06 +0000 (UTC) Received: from crankycanuck.ca (unknown [62.168.35.69]) by mx2.yitter.info (Postfix) with ESMTPSA id AA89010370 for ; Fri, 17 Jul 2015 16:27:05 +0000 (UTC) Date: Fri, 17 Jul 2015 18:27:03 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150717162702.GI14702@crankycanuck.ca> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <559DDE7E.7050201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 16:27:12 -0000 Hi Doug, It's been 7 days since I sent this, and I haven't seen anything from you. You may have noticed that I'm the stuckee for this discussion in Prague. If I don't have slides for it prepared by Saturday night, they may well not get prepared. Currently, what I think your objections are boil down to, "DNS-SD shouldn't use the DNS outside the local link." I therefore think you're challenging the WG's charter, not this document, so I don't really have a way to address your concerns. If you think that's wrong, I really need a clear and concise outline of what you're saying in the next 24 hours, or you'll have to make yourself clear to the WG during the meeting. Best regards, A On Fri, Jul 10, 2015 at 07:31:40PM -0400, Andrew Sullivan wrote: > Hi Doug, > > Apologies for the iphoney top post. I note that the Prague agenda has fully 30 minutes for this discussion, but if we spend all of it trying to understand vocabulary you seem to be introducing we're not going to be successful. Do you think you could create a glossary of some of these terms, or write an email outlining some of the spaces you have in mind or something? I get the impression you have a vision of the name space different to mine, and I'm just not understanding you. > > Thanks, > > A > > -- > Andrew Sullivan > Please excuse my clumbsy thums. > > > On Jul 8, 2015, at 22:37, Douglas Otis wrote: > > > > > > > >> On 7/8/15 7:20 AM, Andrew Sullivan wrote: > >>> On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: > >>> > >>> Section 4.3 seems to conflate DNS as always meaning fully > >>> public global DNS. In the case of mDNS, this is likely not > >>> the case > >> > >> I don't know what you mean by "conflate DNS as always meaning fully > >> public global DNS". It is true _by definition_ that "the DNS" entails > >> a single tree with a single root. It's certainly true that you can > >> arrange things just right so that query-originators to you will see > >> things that query-originators to other name servers will not see. But > >> once you've put things in the DNS, any hope that you have that it will > >> be private -- even in your split-brain arrangements -- are just > >> wishful thinking. We have learned this over and over again, and I > >> don't see why it ought to be controversial; I also don't know how it's > >> relevant here. > > > > Dear Andrew, > > > > Many indicated in some environments there is a need to avoid > > excessive multicast traffic when it negatively impacts > > wireless networks. To avoid resources being resolved using > > mDNS multicast, a different TLD other than .local is needed. > > The draft-ietf-dnssd-hybrid-00 proxy scheme offered a > > fairly automated method for moving mDNS resources into DNS > > which could use an Ambiguous Local Qualified Domain Name > > (ALQDN) space, such as .home as suggested by the draft, or > > even a domain expressed using UTF-8 label locally recognized > > (not encoded and without the 'xn--' prefix). Since often > > these resources are not suitable for the Internet, a > > heuristic to identify zones to be filtered from Internet > > responses based on a "Profile" seems like a viable solution. > > > > Establishing a "Profile" offering heuristics to identify > > suitable global resources makes sense since different > > services normally support local mDNS based resolution which > > ignore IDNA. IMHO, a strategy to globally browse DNS using > > massive responses should be generally discouraged until the > > underlying transport offers effective congestion mitigation. > > DNS amplification leading to DDoS still persists largely > > due to insufficient ingress filtering compliance with BCP38 > > one and a half decades later. That said, DNS-SD may even > > place a campus having just a few compromised systems at risk. > > > >> I also don't know what you mean by the second sentence here, since "in > >> the case of mDNS" is by definition not the public global DNS -- it's a > >> completely different protocol. > > > > Except when mDNS resources are automatically transferred to > > DNS. mDNS is even able to cache DNS resources. > > > >>> Change to: > >>> Operators of internationalized domain names frequently > >>> publish such names in the DNS as A-labels; these A-labels > >>> will be subject to the profile. Any namespace not included > >>> in the profile should be excluded from resolving in a global > >>> context. > >> > >> As I said last time, I don't see what "these A-labels will be subject > >> to the profile" adds and I find it confusing. Moreover, we _cannot_ > >> rule out resolution in the DNS "from resolving in a global context". > >> Here's an example of why. > >> > >> As Stuart has pointed out repeatedly, some enterprises already use > >> DNS-SD in its "wide area" form -- that is, in the DNS. Such a name > >> might have the following form: > >> > >> 3rd Floor Copier Printer.West Wing.example.com > >> > >> In a zone file, that is encoded as > >> > >> 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com > > > > Allowing limited and administrated exceptions is part of the > > dnssd requirement document. That said, it is dangerous to > > tamper with domains having UTF-8 TLD labels and assume these > > resources can be exposed to the Internet. Failing to > > resolve when using non-local tools would be a desired feature. > > > >> The hex encoding of this to the wire format is left as an exercise, > >> but the key point is that when you query (for instance) the > >> example.com zone for that you send the entire owner name as the qname > >> you're trying to look up. Your formulation would prohibit this, and > >> we heard in previous meetings that the WG explicitly does _not_ want > >> that, but instead wants a fallback to the DNS-SD (and for that matter > >> non-IDNA) forms. I think, moreover, that anything that attempts to > >> insist on formal backward incompatibility is doomed to failure. > > > > Not disagreeing. A-Labels can support a heuristic able to > > identify global resources. Wasn't that the purpose of your > > "profile"? Determining when conversions are appropriate? > > > >>> Rather than omitting an important consideration, state the > >>> need for global exclusions. > >> > >> But see above. There is not in fact such a need; rather, stating such > >> a need would be false. > > > > Are you suggesting all locally defined TLDs contained in DNS > > (even when it is able to isolate locally defined TLDs such > > as .home) must always be encoded per IDNA? If properly > > identified by a Profile, the Internet should never see these > > resources. Such a strategy should allow desired multicast > > avoidance (such as not using .local. ) without otherwise > > changing local namespace handling routines as used with mDNS. > > > >>> The point missed seems related to risks caused by not > >>> differentiating local and global namespaces as illustrated > >>> in the following examples. > >> > >> You seem to think that there are "local" and "global" namespaces and > >> we know which is which in advance. But we don't. That's _exactly_ > >> the problem. If we knew that in advance, we would know which > >> resolution system to use, and we would have no issue at all. > > > > A profile should also establish the labels accessible only > > using local resolution tools. Use of '_' already carves out > > encoding exceptions for hosts and instances label. Why not > > carve out entire local zones that are to be excluded from > > various resolvers and interfaces? > > > >>> A DDoS risk occurs whenever RFC6763 DNS-SD resources are > >>> given Internet accessed from either mDNS or DNS servers. > >> > >> There is no such thing as an mDNS server. > > > > IMHO, an mDNS node acts as its own server when conveying its > > resources. > > > >> I'm having an increasingly > >> hard time understanding what you're talking about, and I'm > >> decreasingly convinced that this is because of a fault in my own > >> understanding. DDoS is a risk from large answers in the DNS; this is > >> well known. I do not believe that this document is the place to > >> attempt to discuss that in detail. To begin with, DNSOP is another > >> WG. I see nothing wrong with writing a document from DNSOP saying, > >> "Large answer sets present a danger to DNS operations," but I don't > >> believe that one needs to repeat that advice in every single document > >> anywhere that mentions the DNS. > > > > The situation is serious but not fatal if caution were to > > prevail. > > > >>> See RFC6763 Section 7.2. Granting brows-able access to > >>> DNS-SD resources using either mDNS or DNS resolvers allows a > >>> wildcard at an instance location to respond with as many as > >>> 839 separate and combined resources. Blocking wildcard use > >>> defeats its intended use, normally safe on a local network. > >> > >> So, do you want the security considerations section to have a sentence > >> that says, "Any use of the DNS that follows the outlines of this > >> document necessarily incurs all DDoS risks resulting from the use of > >> DNS"? I'm prepared to add that if you like. > > > > It seems it would be more constructive as part of a > > comprehensive strategy. > > > >>> It is not clear why mDNS resources moved to DNS > >> > >> I don't have any clue what that means. There are no "mDNS resources" > >> that "move to DNS". Those are different protocols. > >> > >>> DNS-SD is structured differently. It combines a large > >>> number of sizable service RRsets below an Instance node. > >> > >> Sure. It's a use of the DNS. You seem to be making an argument that > >> DNS-SD is unsafe for use on the Internet, period. > > > > Don't ignore issues the hybrid scheme attempts to solve > > (with the aid of careful administration in specific cases to > > reduce the risk). Risks demand either clearly defined > > prohibitions against local UTF-8 namespace in DNS (which > > seems unlikely) or properly identified handling profiles, > > which should be the purpose of this document. > > > >> If that's your > >> argument, then please publish "DNS-SD considered dangerous in the DNS" > >> or something like that. This draft is about what you would do to make > >> DNS-SD work predictably _assuming_ that you wanted to use more than > >> one resolution mechanism, one of which is DNS, and I think including > >> text about why DNS-SD is dangerous is going to be mighty confusing. > >> If the WG concludes that DNS-SD is in fact dangerous for Internet use, > >> then obviously this draft shouldn't be published at all because you > >> shouldn't try to do any of these things in the first place. > > > > Thanks for the encouragement. I have discussed various > > solutions with others having extensive DNS knowledge. Any > > general solution will likely arrive too late to avoid > > sizable problems that could occur when needlessly exposing > > DNS-SD resources to the Internet. Allowing a few > > administratively managed exceptions should be fine and > > keeping within the dnssd requirements. > > > >>> Labels do not afford operational protection from DDoS or > >>> vulnerability exposure whether defined as A-labels, U-labels > >>> or neither. > >> > >> Yes. The current draft has nothing to do with DDoS risk from the use > >> of the DNS, and I agree it is completely silent on that topic. I > >> think that's a feature, but I'm willing to include the sentence noted > >> above if that will help. > > > > Perhaps you can see where this might be headed. Something > > along the lines of a profile exclusion of local resources, > > to facilitate the conveying of these resources to only local > > resolver tools that understand the specific needed > > conversions and the scope of their access. A strategy > > mimicking what is currently based on mDNS. > > > >>> mDNS is inherently safer because it normally is > >>> only accessible from the local network. An issue this draft > >>> continues to ignore, even when confronting a CERT notice! > >> > >> Uh, the CERT notice you sent was complaining about mDNS _not_ being > >> accessible only from the local network, which is what the problem was. > >> That has absolutely nothing to do with DNS-anythingelse > >> interoperation. > > > > Review researcher's notes at: > > https://github.com/chadillac/mdns_recon > > > > The concerns relate specifically to access granted to mDNS > > resources. Unfettered access may create a rather bleak > > situation that can be salvaged by administratively placing > > only key resources into non-local zones. (i.e. not in a > > default .home or its multilingual equivalent.) > > > > Appendix notes found in > > http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 > > previously noted on this mailing-lists about 6 months prior > > further supports these findings. > > > >>> DNS-SD describes a structure intended to be browsed and > >>> displayed having user friendly encoding. > >> > >> Wait. So your issue is that DNS-SD owner names are intended to be > >> seen by humans? > > > > Clearly an issue whenever IDNA encoding is imposed on > > exclusively local resources where user interfaces don't > > support their conversion. > > > >>> Tools to browse DNS-SD DO NOT employ encoding used by > >>> IDNA2008 > >> > >> Yes, which is why only the portion is treated as though it > >> needs to be processed by IDNA. This is mostly because that's where > >> the names will be in the DNS. The rest of the Service Instance Name > >> continues to work according to the DNS-SD specification, and there are > >> no mitigations of any sort about the possibly large number of names > >> below the portion of a Service Instance Name. That's because > >> we're using DNS-SD. > > > > Which is why there should be a strategy to restrict global > > access to just resources that are administratively permitted. > > > >>> to be applied, but these actions are normally NEVER needed. > >> > >> The point of the draft, which I think is explained pretty clearly in > >> the introduction, is that you'll need the IDNA processing for the > >> portion or else DNS will just return RCODE 3 and you won't > >> find what you're looking for. > >> > >>>> I disagree. mDNS uses the full repertoire of octets available in the > >>>> DNS. DNS operators as a matter of fact (for various reasons explained > >>>> elsewhere) use a subset of those octets. > >>> > >>> DNS is able to use the SAME octets as used by mDNS. > >> > >> Yes, which is entirely consistent with what I said. > >> > >>> There > >>> might be cases where global DNS and local DNS wish to share > >>> a common zone for reasons likely related to use of > >>> certificates or minimizing servers. > >> > >> What exactly is "local DNS"? > > > > This might employ a split horizon server excluding interface > > and resolver access from specifically "profiled" zones. > > > >>> We see the problem differently. There is a real danger > >>> attempting to combine these two different namespaces, > >> > >> I think what you're saying is that the goal of the draft is dangerous > >> and bad. That's ok with me, but it seems really to be an argument > >> that the WG shouldn't try to do what it is chartered to do, no? > > > > This and the poor track record for BCP38 should motivate DNS > > transport improvements in the long run. In the meantime, > > not aggressively globally deploying DNS-SD should be an > > appropriate and conservative strategy. > > > > Regards, > > Douglas Otis > > > > > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Andrew Sullivan ajs@crankycanuck.ca From nobody Sat Jul 18 06:21:12 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6241B2C77 for ; Sat, 18 Jul 2015 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 5DEiq9dy3DQD for ; Sat, 18 Jul 2015 06:21:08 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 D5D0B1B2C76 for ; Sat, 18 Jul 2015 06:21:07 -0700 (PDT) Received: by oibn4 with SMTP id n4so85643304oib.3 for ; Sat, 18 Jul 2015 06:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=k7q8GfJgAUI/9wxl8jI+cFiIAENEk6M4FMkokkQNU58=; b=SAhrA0Kau5iRI2C+541KVeF27xBMsuZxd87VgOeOnT2YjlgKwiKui3esvVmPXIs81W TfXBN+1Zhw4i3TVCQLjf1yffdrgOyqG7XsKlId115bAATQOFo/9KIF2/UnL/uJDwo50B zI8Em1S+bTMpSfDseHLe9mnmZC65B+y1Yc2/EUbs9iTug4uaJH7RWDvsN7cAUS1bgvPw lcH1jQLB4aZajeRLeK8nQ+iGkim+/T/hatXv1CwB0EFHgDvCpKFZUQJeIlIFwbc716x4 rrLFqA4Fp/hiVl/mIkToxf3QdF41iMYgEwxFmUzpXyz8o8BCeEkABnPJ/w4AOj1TQZgL D9uQ== X-Received: by 10.202.218.132 with SMTP id r126mr17043964oig.69.1437225667321; Sat, 18 Jul 2015 06:21:07 -0700 (PDT) Received: from US-DOUGO-MAC.local (smb-adpcdg1-05.hotspot.hub-one.net. [213.174.99.133]) by smtp.googlemail.com with ESMTPSA id rz6sm8031099obb.15.2015.07.18.06.21.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 06:21:05 -0700 (PDT) From: Douglas Otis To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <559DDE7E.7050201@gmail.com> <20150717162702.GI14702@crankycanuck.ca> X-Enigmail-Draft-Status: N1110 Message-ID: <55AA52BA.4040909@gmail.com> Date: Sat, 18 Jul 2015 15:20:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150717162702.GI14702@crankycanuck.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 13:21:11 -0000 On 7/17/15 9:27 AM, Andrew Sullivan wrote: > Hi Doug, > > It's been 7 days since I sent this, and I haven't seen anything from > you. You may have noticed that I'm the stuckee for this discussion in > Prague. If I don't have slides for it prepared by Saturday night, > they may well not get prepared. Currently, what I think your > objections are boil down to, "DNS-SD shouldn't use the DNS outside the > local link." I therefore think you're challenging the WG's charter, > not this document, so I don't really have a way to address your > concerns. If you think that's wrong, I really need a clear and > concise outline of what you're saying in the next 24 hours, or you'll > have to make yourself clear to the WG during the meeting. Dear Andrew, Sorry for the delay. I have been attending the MacIT Conference while seeking inputs from others and reviewing an impressive number of upcoming changes to OS X and iOS networking solutions. Unfortunately, documentation at this time seems a bit scant. Soon enterprise configurations will be able to arrange extensive tunneling to resolve mDNS resources as a type of namespace overlay without configuration size limits being a problem. The chartered goal was largely aimed at solving Apple's connectivity issues within school environments. Satisfying such a goal should be met while also not exposing hybrid resources to the Internet or while strictly moderating the amount of mDNS resources exposed. Standard DNS lacks many of the mitigation techniques used with mDNS such as Opportunistic Caching, Duplicate Query Suppression, Passive Observation Of Failures (POOF), Passive Conflict Detection, and redefined NSEC functions. That said, the high levels of multicast traffic has been negatively affecting WiFi networks which transfer this extensive amount of data at the lowest possible rate. mDNS also did not support hashed multicast addresses because the service was intended to discover names and avoiding naming conflicts was only secondary. This means DNS-SD effects for either mDNS or DNS will be pervasive. The last thing Apple or schools are likely to want is an scheme by the IETF that becomes a major security risk for those using it or for the Internet in general. What I was suggesting was to discuss a general strategy that best avoids DDoS and vulnerability exposures. This might be done by identifying a locally defined domain (other than .local) to be used. Ambiguous Local Qualified Domain Name (ALQDN) space (See RFC7368), such as .home as suggested by the draft, or even a domain expressed using UTF-8 label locally recognized (not encoded and without the 'xn--' prefix). A local domain might be defined as not having an ('xn--' prefix while using utf-8 encoding or the special domain .home, or resources having addresses within RFC1918 space or below a ULA prefix. I hope to be at the meeting, if that helps. Regards, Douglas Otis >>> On Jul 8, 2015, at 22:37, Douglas Otis wrote: >>> >>>> On 7/8/15 7:20 AM, Andrew Sullivan wrote: >>>>> On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: >>>>> >>>>> Section 4.3 seems to conflate DNS as always meaning fully >>>>> public global DNS. In the case of mDNS, this is likely not >>>>> the case >>>> >>>> I don't know what you mean by "conflate DNS as always meaning fully >>>> public global DNS". It is true _by definition_ that "the DNS" entails >>>> a single tree with a single root. It's certainly true that you can >>>> arrange things just right so that query-originators to you will see >>>> things that query-originators to other name servers will not see. But >>>> once you've put things in the DNS, any hope that you have that it will >>>> be private -- even in your split-brain arrangements -- are just >>>> wishful thinking. We have learned this over and over again, and I >>>> don't see why it ought to be controversial; I also don't know how it's >>>> relevant here. >>> >>> Dear Andrew, >>> >>> Many indicated in some environments there is a need to avoid >>> excessive multicast traffic when it negatively impacts >>> wireless networks. To avoid resources being resolved using >>> mDNS multicast, a different TLD other than .local is needed. >>> The draft-ietf-dnssd-hybrid-00 proxy scheme offered a >>> fairly automated method for moving mDNS resources into DNS >>> which could use an Ambiguous Local Qualified Domain Name >>> (ALQDN) space, such as .home as suggested by the draft, or >>> even a domain expressed using UTF-8 label locally recognized >>> (not encoded and without the 'xn--' prefix). Since often >>> these resources are not suitable for the Internet, a >>> heuristic to identify zones to be filtered from Internet >>> responses based on a "Profile" seems like a viable solution. >>> >>> Establishing a "Profile" offering heuristics to identify >>> suitable global resources makes sense since different >>> services normally support local mDNS based resolution which >>> ignore IDNA. IMHO, a strategy to globally browse DNS using >>> massive responses should be generally discouraged until the >>> underlying transport offers effective congestion mitigation. >>> DNS amplification leading to DDoS still persists largely >>> due to insufficient ingress filtering compliance with BCP38 >>> one and a half decades later. That said, DNS-SD may even >>> place a campus having just a few compromised systems at risk. >>> >>>> I also don't know what you mean by the second sentence here, since "in >>>> the case of mDNS" is by definition not the public global DNS -- it's a >>>> completely different protocol. >>> >>> Except when mDNS resources are automatically transferred to >>> DNS. mDNS is even able to cache DNS resources. >>> >>>>> Change to: >>>>> Operators of internationalized domain names frequently >>>>> publish such names in the DNS as A-labels; these A-labels >>>>> will be subject to the profile. Any namespace not included >>>>> in the profile should be excluded from resolving in a global >>>>> context. >>>> >>>> As I said last time, I don't see what "these A-labels will be subject >>>> to the profile" adds and I find it confusing. Moreover, we _cannot_ >>>> rule out resolution in the DNS "from resolving in a global context". >>>> Here's an example of why. >>>> >>>> As Stuart has pointed out repeatedly, some enterprises already use >>>> DNS-SD in its "wide area" form -- that is, in the DNS. Such a name >>>> might have the following form: >>>> >>>> 3rd Floor Copier Printer.West Wing.example.com >>>> >>>> In a zone file, that is encoded as >>>> >>>> 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com >>> >>> Allowing limited and administrated exceptions is part of the >>> dnssd requirement document. That said, it is dangerous to >>> tamper with domains having UTF-8 TLD labels and assume these >>> resources can be exposed to the Internet. Failing to >>> resolve when using non-local tools would be a desired feature. >>> >>>> The hex encoding of this to the wire format is left as an exercise, >>>> but the key point is that when you query (for instance) the >>>> example.com zone for that you send the entire owner name as the qname >>>> you're trying to look up. Your formulation would prohibit this, and >>>> we heard in previous meetings that the WG explicitly does _not_ want >>>> that, but instead wants a fallback to the DNS-SD (and for that matter >>>> non-IDNA) forms. I think, moreover, that anything that attempts to >>>> insist on formal backward incompatibility is doomed to failure. >>> >>> Not disagreeing. A-Labels can support a heuristic able to >>> identify global resources. Wasn't that the purpose of your >>> "profile"? Determining when conversions are appropriate? >>> >>>>> Rather than omitting an important consideration, state the >>>>> need for global exclusions. >>>> >>>> But see above. There is not in fact such a need; rather, stating such >>>> a need would be false. >>> >>> Are you suggesting all locally defined TLDs contained in DNS >>> (even when it is able to isolate locally defined TLDs such >>> as .home) must always be encoded per IDNA? If properly >>> identified by a Profile, the Internet should never see these >>> resources. Such a strategy should allow desired multicast >>> avoidance (such as not using .local. ) without otherwise >>> changing local namespace handling routines as used with mDNS. >>> >>>>> The point missed seems related to risks caused by not >>>>> differentiating local and global namespaces as illustrated >>>>> in the following examples. >>>> >>>> You seem to think that there are "local" and "global" namespaces and >>>> we know which is which in advance. But we don't. That's _exactly_ >>>> the problem. If we knew that in advance, we would know which >>>> resolution system to use, and we would have no issue at all. >>> >>> A profile should also establish the labels accessible only >>> using local resolution tools. Use of '_' already carves out >>> encoding exceptions for hosts and instances label. Why not >>> carve out entire local zones that are to be excluded from >>> various resolvers and interfaces? >>> >>>>> A DDoS risk occurs whenever RFC6763 DNS-SD resources are >>>>> given Internet accessed from either mDNS or DNS servers. >>>> >>>> There is no such thing as an mDNS server. >>> >>> IMHO, an mDNS node acts as its own server when conveying its >>> resources. >>> >>>> I'm having an increasingly >>>> hard time understanding what you're talking about, and I'm >>>> decreasingly convinced that this is because of a fault in my own >>>> understanding. DDoS is a risk from large answers in the DNS; this is >>>> well known. I do not believe that this document is the place to >>>> attempt to discuss that in detail. To begin with, DNSOP is another >>>> WG. I see nothing wrong with writing a document from DNSOP saying, >>>> "Large answer sets present a danger to DNS operations," but I don't >>>> believe that one needs to repeat that advice in every single document >>>> anywhere that mentions the DNS. >>> >>> The situation is serious but not fatal if caution were to >>> prevail. >>> >>>>> See RFC6763 Section 7.2. Granting brows-able access to >>>>> DNS-SD resources using either mDNS or DNS resolvers allows a >>>>> wildcard at an instance location to respond with as many as >>>>> 839 separate and combined resources. Blocking wildcard use >>>>> defeats its intended use, normally safe on a local network. >>>> >>>> So, do you want the security considerations section to have a sentence >>>> that says, "Any use of the DNS that follows the outlines of this >>>> document necessarily incurs all DDoS risks resulting from the use of >>>> DNS"? I'm prepared to add that if you like. >>> >>> It seems it would be more constructive as part of a >>> comprehensive strategy. >>> >>>>> It is not clear why mDNS resources moved to DNS >>>> >>>> I don't have any clue what that means. There are no "mDNS resources" >>>> that "move to DNS". Those are different protocols. >>>> >>>>> DNS-SD is structured differently. It combines a large >>>>> number of sizable service RRsets below an Instance node. >>>> >>>> Sure. It's a use of the DNS. You seem to be making an argument that >>>> DNS-SD is unsafe for use on the Internet, period. >>> >>> Don't ignore issues the hybrid scheme attempts to solve >>> (with the aid of careful administration in specific cases to >>> reduce the risk). Risks demand either clearly defined >>> prohibitions against local UTF-8 namespace in DNS (which >>> seems unlikely) or properly identified handling profiles, >>> which should be the purpose of this document. >>> >>>> If that's your >>>> argument, then please publish "DNS-SD considered dangerous in the DNS" >>>> or something like that. This draft is about what you would do to make >>>> DNS-SD work predictably _assuming_ that you wanted to use more than >>>> one resolution mechanism, one of which is DNS, and I think including >>>> text about why DNS-SD is dangerous is going to be mighty confusing. >>>> If the WG concludes that DNS-SD is in fact dangerous for Internet use, >>>> then obviously this draft shouldn't be published at all because you >>>> shouldn't try to do any of these things in the first place. >>> >>> Thanks for the encouragement. I have discussed various >>> solutions with others having extensive DNS knowledge. Any >>> general solution will likely arrive too late to avoid >>> sizable problems that could occur when needlessly exposing >>> DNS-SD resources to the Internet. Allowing a few >>> administratively managed exceptions should be fine and >>> keeping within the dnssd requirements. >>> >>>>> Labels do not afford operational protection from DDoS or >>>>> vulnerability exposure whether defined as A-labels, U-labels >>>>> or neither. >>>> >>>> Yes. The current draft has nothing to do with DDoS risk from the use >>>> of the DNS, and I agree it is completely silent on that topic. I >>>> think that's a feature, but I'm willing to include the sentence noted >>>> above if that will help. >>> >>> Perhaps you can see where this might be headed. Something >>> along the lines of a profile exclusion of local resources, >>> to facilitate the conveying of these resources to only local >>> resolver tools that understand the specific needed >>> conversions and the scope of their access. A strategy >>> mimicking what is currently based on mDNS. >>> >>>>> mDNS is inherently safer because it normally is >>>>> only accessible from the local network. An issue this draft >>>>> continues to ignore, even when confronting a CERT notice! >>>> >>>> Uh, the CERT notice you sent was complaining about mDNS _not_ being >>>> accessible only from the local network, which is what the problem was. >>>> That has absolutely nothing to do with DNS-anythingelse >>>> interoperation. >>> >>> Review researcher's notes at: >>> https://github.com/chadillac/mdns_recon >>> >>> The concerns relate specifically to access granted to mDNS >>> resources. Unfettered access may create a rather bleak >>> situation that can be salvaged by administratively placing >>> only key resources into non-local zones. (i.e. not in a >>> default .home or its multilingual equivalent.) >>> >>> Appendix notes found in >>> http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 >>> previously noted on this mailing-lists about 6 months prior >>> further supports these findings. >>> >>>>> DNS-SD describes a structure intended to be browsed and >>>>> displayed having user friendly encoding. >>>> >>>> Wait. So your issue is that DNS-SD owner names are intended to be >>>> seen by humans? >>> >>> Clearly an issue whenever IDNA encoding is imposed on >>> exclusively local resources where user interfaces don't >>> support their conversion. >>> >>>>> Tools to browse DNS-SD DO NOT employ encoding used by >>>>> IDNA2008 >>>> >>>> Yes, which is why only the portion is treated as though it >>>> needs to be processed by IDNA. This is mostly because that's where >>>> the names will be in the DNS. The rest of the Service Instance Name >>>> continues to work according to the DNS-SD specification, and there are >>>> no mitigations of any sort about the possibly large number of names >>>> below the portion of a Service Instance Name. That's because >>>> we're using DNS-SD. >>> >>> Which is why there should be a strategy to restrict global >>> access to just resources that are administratively permitted. >>> >>>>> to be applied, but these actions are normally NEVER needed. >>>> >>>> The point of the draft, which I think is explained pretty clearly in >>>> the introduction, is that you'll need the IDNA processing for the >>>> portion or else DNS will just return RCODE 3 and you won't >>>> find what you're looking for. >>>> >>>>>> I disagree. mDNS uses the full repertoire of octets available in the >>>>>> DNS. DNS operators as a matter of fact (for various reasons explained >>>>>> elsewhere) use a subset of those octets. >>>>> >>>>> DNS is able to use the SAME octets as used by mDNS. >>>> >>>> Yes, which is entirely consistent with what I said. >>>> >>>>> There >>>>> might be cases where global DNS and local DNS wish to share >>>>> a common zone for reasons likely related to use of >>>>> certificates or minimizing servers. >>>> >>>> What exactly is "local DNS"? >>> >>> This might employ a split horizon server excluding interface >>> and resolver access from specifically "profiled" zones. >>> >>>>> We see the problem differently. There is a real danger >>>>> attempting to combine these two different namespaces, >>>> >>>> I think what you're saying is that the goal of the draft is dangerous >>>> and bad. That's ok with me, but it seems really to be an argument >>>> that the WG shouldn't try to do what it is chartered to do, no? >>> >>> This and the poor track record for BCP38 should motivate DNS >>> transport improvements in the long run. In the meantime, >>> not aggressively globally deploying DNS-SD should be an >>> appropriate and conservative strategy. >>> >>> Regards, >>> Douglas Otis >>> >>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd > From nobody Sat Jul 18 12:23:05 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5421A1BF5 for ; Sat, 18 Jul 2015 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 H3I0QluPhbrb for ; Sat, 18 Jul 2015 12:23:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86221A0378 for ; Sat, 18 Jul 2015 12:23:01 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.225.13; Sat, 18 Jul 2015 19:22:39 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0225.013; Sat, 18 Jul 2015 19:22:39 +0000 From: Dave Thaler To: "dnssd@ietf.org" , Andrew Sullivan Thread-Topic: WG last call on draft-ietf-dnssd-mdns-dns-interop-01 Thread-Index: AQHQuGeHLuddF6mW6Uq1LgQt1EI5VJ3cpFUAgATnBDA= Date: Sat, 18 Jul 2015 19:22:39 +0000 Message-ID: References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> In-Reply-To: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [64.134.100.3] x-microsoft-exchange-diagnostics: 1; BY2PR03MB412; 5:SOrrbcyd7Kd6tER6fL+eHjYh/yv9IW5ct01wb22wj0JhomMD8fPFRG+Zs4xpAfGZdbsNgk21rTDqH0ZbjhacbuNyh22xl6L69CllcfLWXym1HdLgSqgaWRZAS/zfFdn4SwWcH8KjHIOpJtxVg3Y8Nw==; 24:gpkm/y0V5C6ubna+wLNeaK3V2u/5YAg9v2sIQWKX60p9rv21RcBDRi4m463WK0g6RVLU5nLhbvpQmLU5WCmTtSkKw+Jny1vYBY69slwOn3E=; 20:IcWhZyd3lXxL1FmFuWROyrXpmnJDd/Z9ZS/nvQWsgYtUljUMuxdfYRCZKHPjHLr2YLq2SvhsMi8QFHfQRc/H1Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; by2pr03mb412: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0641678E68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(13464003)(377454003)(66066001)(77156002)(62966003)(5002640100001)(40100003)(46102003)(86362001)(74316001)(2950100001)(106116001)(122556002)(77096005)(189998001)(102836002)(15975445007)(76576001)(99286002)(5003600100002)(107886002)(5001960100002)(86612001)(92566002)(33656002)(19580405001)(19580395003)(76176999)(2656002)(54356999)(230783001)(5001920100001)(2501003)(50986999)(5001770100001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2015 19:22:39.5861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 19:23:04 -0000 I read draft -01 and it looks good to me, modulo a few editorial nits: 1) First sentence of section 3 missing end parenthesis: > Any interoperability between DNS (including prevailing operational > conventions and other resolution technologies will require I believe the end parenthesis belongs after "conventions". 2) Security Considerations: > This memo presents some requirements for future development, but does > not specify anything. Therefore, it has no implications for security. The second sentence does not logically follow from the first sentence. Specifically, does this memo surface any special requirements for security?= =20 If not, just say there are no additional security-specific requirements. 3) Appendix A: Add note to RFC editor to remove this section before publica= tion? Dave -----Original Message----- From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Ralph Droms (rdrom= s) Sent: Wednesday, July 15, 2015 7:29 AM To: dnssd@ietf.org Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 Reminder - the WG last call for draft-ietf-dnssd-mdns-dns-interop is in pro= gress and we will discuss any last call comments during the WG meeting in P= rague. - Ralph > On Jul 6, 2015, at 11:46 PM 7/6/15, Ralph Droms (rdroms) wrote: >=20 > Hi, >=20 > This email begins a two week WGLC on draft-ietf-dnssd-mdns-dns-interop-01= , "On Interoperation of Labels Between mDNS and DNS". >=20 > Tim and I believe the author has addressed the issues first brought forwa= rd at IETF-92 and subsequently discussed on the WG mailing list.=20 >=20 > You can see the draft here: > http://www.ietf.org/id/draft-ietf-dnssd-mdns-dns-interop-01.txt >=20 > Please send your comments or feedback to the list. >=20 > The WGLC ends on July 20th (Monday). >=20 > We will discuss/consider the result of the WGLC at the dnssd session at I= ETF-93 in Prague, which is scheduled for 9AM Wednesday, July 22. >=20 > - Ralph >=20 _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jul 18 13:29:44 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD61A038C for ; Sat, 18 Jul 2015 13:29:43 -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] autolearn=ham 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 G9iG4ylZWFMm for ; Sat, 18 Jul 2015 13:29:41 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C11A0235 for ; Sat, 18 Jul 2015 13:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 162D71000B for ; Sat, 18 Jul 2015 20:29:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE94qXb8km4q for ; Sat, 18 Jul 2015 20:29:40 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2001:df8:ffff:4:b9cd:53a9:b751:9d7d]) by mx2.yitter.info (Postfix) with ESMTPSA id 09A0F105DB for ; Sat, 18 Jul 2015 20:29:39 +0000 (UTC) Date: Sat, 18 Jul 2015 22:29:37 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150718202937.GC18337@mx2.yitter.info> References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 20:29:43 -0000 On Sat, Jul 18, 2015 at 07:22:39PM +0000, Dave Thaler wrote: > 1) First sentence of section 3 missing end parenthesis: > > Any interoperability between DNS (including prevailing operational > > conventions and other resolution technologies will require > > I believe the end parenthesis belongs after "conventions". Thanks, yes. > > 2) Security Considerations: > > This memo presents some requirements for future development, but does > > not specify anything. Therefore, it has no implications for security. > > The second sentence does not logically follow from the first sentence. > Specifically, does this memo surface any special requirements for security? > If not, just say there are no additional security-specific requirements. Well, _I_ don't think there are any more. Doug seems to think so, but I can't exactly make out what he wants. > 3) Appendix A: Add note to RFC editor to remove this section before publication? > Sure, thanks. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Jul 18 21:31:42 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641351A7025 for ; Sat, 18 Jul 2015 21:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 tUiJ2y23FBqi for ; Sat, 18 Jul 2015 21:31:38 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 B45EC1A1EF5 for ; Sat, 18 Jul 2015 21:31:38 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so85693313obb.0 for ; Sat, 18 Jul 2015 21:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=IcpVrvXnQDTRCPWHGaOwRvt0rUge8q6lransoovrLMc=; b=NmfYswSgBKWEvJTCm1flO9vuLYh3KDFh5uKWP0TFlCJEexE4vc7zEfx1XJHb42gKtP 5nxrF+99rQTmf759m0t2mew8l8hfbdEr/SvE/ZpJTlO/ZE19uFScq6uyvyCOqcBOSz7t ql74VuqlWW/92DBOXI/Jgrossn4x1N0okvhSnxKAkd+O2zHhN+IF76eggcnZVfETAfBR /GKA+7s3kUq/4SU21B30e1qNCidFKSt1vRG/02K4ThlV1cjW6ckXX9fuSnPeD8SZ+N6+ yR7yg/JsNbhlU74IHhb9PJBdekSr0w5cR+bdDWHTAqypLz75wBd/e//9BUHwiChciyP+ EeRw== X-Received: by 10.202.56.9 with SMTP id f9mr19460916oia.126.1437280298231; Sat, 18 Jul 2015 21:31:38 -0700 (PDT) Received: from US-DOUGO-MAC.local ([89.248.140.9]) by smtp.googlemail.com with ESMTPSA id c3sm9394692obo.5.2015.07.18.21.31.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 21:31:37 -0700 (PDT) To: dnssd@ietf.org References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> <20150718202937.GC18337@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <55AB2827.6080003@gmail.com> Date: Sun, 19 Jul 2015 06:31:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150718202937.GC18337@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 04:31:40 -0000 On 7/18/15 10:29 PM, Andrew Sullivan wrote: > On Sat, Jul 18, 2015 at 07:22:39PM +0000, Dave Thaler wrote: >> 1) First sentence of section 3 missing end parenthesis: >>> Any interoperability between DNS (including prevailing operational >>> conventions and other resolution technologies will require >> >> I believe the end parenthesis belongs after "conventions". > > Thanks, yes. > >> >> 2) Security Considerations: >>> This memo presents some requirements for future development, but does >>> not specify anything. Therefore, it has no implications for security. >> >> The second sentence does not logically follow from the first sentence. >> Specifically, does this memo surface any special requirements for security? >> If not, just say there are no additional security-specific requirements. > > Well, _I_ don't think there are any more. Doug seems to think so, but > I can't exactly make out what he wants. > >> 3) Appendix A: Add note to RFC editor to remove this section before publication? Dear Andrew, As noted in https://www.kb.cert.org/vuls/id/550620 https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.4.1 https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.5 There are specific and significant security concerns related to locally defined resources conveyed by mDNS. Interop details relating to profiles might benefit security by including a strategy to ascertain whether zones or labels may have been established using mDNS via a proxy into DNS. This might include the detection of a non-compliant IDNA label or resources containing RFC1918 address space or addresses below a ULA prefix. Regards, Douglas Otis From nobody Sun Jul 19 00:21:23 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACDF1A0AC8 for ; Sun, 19 Jul 2015 00:21:20 -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] autolearn=ham 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 13XqCvQdXn8i for ; Sun, 19 Jul 2015 00:21:18 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id C87351A044D for ; Sun, 19 Jul 2015 00:21:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 4C94110370 for ; Sun, 19 Jul 2015 07:21:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS7z8LZ3sd9O for ; Sun, 19 Jul 2015 07:21:16 +0000 (UTC) Received: from mx2.yitter.info (dhcp-b10d.meeting.ietf.org [31.133.177.13]) by mx2.yitter.info (Postfix) with ESMTPSA id E782610012 for ; Sun, 19 Jul 2015 07:21:15 +0000 (UTC) Date: Sun, 19 Jul 2015 09:21:13 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150719072113.GE18688@mx2.yitter.info> References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> <20150718202937.GC18337@mx2.yitter.info> <55AB2827.6080003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AB2827.6080003@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 07:21:20 -0000 Hi, On Sun, Jul 19, 2015 at 06:31:35AM +0200, Douglas Otis wrote: > As noted in > https://www.kb.cert.org/vuls/id/550620 > https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.4.1 > https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.5 > > There are specific and significant security concerns related > to locally defined resources conveyed by mDNS. I'm sorry, but I simply do not agree with your interpretation of those reports and _anyway_ I don't see how those are in related to the question of how you make a lowest common denominator naming convention across multiple resolution mechanisms. You have repeated the claim that these are relevant, but you have provided not one shred of evidence for that claim, and you seem to be conflating mDNS and DNS-SD in the way you talk about this matter. > Interop > details relating to profiles might benefit security by > including a strategy to ascertain whether zones or labels > may have been established using mDNS via a proxy into DNS. Given the way the proxy document works, I don't believe that the risks are the ones you seem to think. Moreover, I think that would be a security issue for the proxy document, not this one. > This might include the detection of a non-compliant IDNA > label or resources containing RFC1918 address space or > addresses below a ULA prefix. This document has absolutely nothing to say about the RDATA fields returned in any resolution request, and I don't think that has anything to do with what it is trying to address. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Jul 19 04:46:27 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38991ACD40 for ; Sun, 19 Jul 2015 04:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 dAU6FTuMN2np for ; Sun, 19 Jul 2015 04:46:25 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 2B0C31ACD3F for ; Sun, 19 Jul 2015 04:46:25 -0700 (PDT) Received: by oigd21 with SMTP id d21so52054248oig.1 for ; Sun, 19 Jul 2015 04:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=x4T7PKWYrNQXKmgcw6zhgRxY4LlLkTxZV//ZAT9RqpY=; b=FXUyCDJ8/UKrBmFa256JFdUV4gw3Or5LJyByAi88jgRfpUnLjKmj4Qz1xaYLzR4zJo vQ3zsbwXdGBJU4ZB4Bxcf8FuUP8AV+Cb/T90k++WFmGot+TfoxX/YTmwySofNldRE7e9 2RIlGXpHFNQayURXerGSRBDiGmyuZxml/t4NEaYE2VgIXnbwy0EDCPz4ExMMM4mAQ0lD 5TFk/yUvBuPjzCuaAREqgl60kwganXm28QfP8/bKAsSxqSmlwLInZyCConbijFF/nWtI FTljxMRPlIs+Gxo9kC8oB/xps9gEHnVgBTk4ZcsRbqACjzetQ+pP/4tx869/LLio71wq HyOA== X-Received: by 10.182.230.234 with SMTP id tb10mr22362759obc.23.1437306384640; Sun, 19 Jul 2015 04:46:24 -0700 (PDT) Received: from US-DOUGO-MAC.local ([31.30.2.5]) by smtp.googlemail.com with ESMTPSA id y131sm9929642oig.28.2015.07.19.04.46.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jul 2015 04:46:24 -0700 (PDT) To: dnssd@ietf.org References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> <20150718202937.GC18337@mx2.yitter.info> <55AB2827.6080003@gmail.com> <20150719072113.GE18688@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <55AB8E0D.302@gmail.com> Date: Sun, 19 Jul 2015 13:46:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150719072113.GE18688@mx2.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 11:46:26 -0000 On 7/19/15 9:21 AM, Andrew Sullivan wrote: > Hi, > > On Sun, Jul 19, 2015 at 06:31:35AM +0200, Douglas Otis wrote: >> As noted in >> https://www.kb.cert.org/vuls/id/550620 >> https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.4.1 >> https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.5 >> >> There are specific and significant security concerns related >> to locally defined resources conveyed by mDNS. > > I'm sorry, but I simply do not agree with your interpretation of those > reports and _anyway_ I don't see how those are in related to the > question of how you make a lowest common denominator naming convention > across multiple resolution mechanisms. Dear Andrew, I see mDNS and DNS-SD when populated from a hybrid scheme as representing the same fruit. Both mDNS and DNS-SD are able to respond with sizable RRsets by design. Responses that may only be suitable with local exchanges structured to facilitate service browsing. Also, in the case of the hybrid scheme, a TLD of say '.home' is using Ambiguous Local Qualified Domain Name (ALQDN) space (see RFC7368). TLDs containing such resources are not held to common conventions and may allow visual conflicts, for example. It seems provincial to suggest only .home or that only IDNA compatible names are to be used in conjunction with an mDNS/DNS-SD hybrid scheme. As such, a common naming convention may not exist. When a naming dichotomy is ignored, whether '.home', '.onion', or perhaps '.domů', resulting incongruities may carry substantial security risks. A practical solution may demand a strategy that excludes the majority of mDNS resources structured as DNS-SD from being directly seen on the Internet. Establishing guidance to handle very different name spaces might be seen as a type of profile. Less will be accomplished asserting mDNS/DNS-SD issues are matters for DNS or the Hybrid document to handle since both establish separate name spaces while also introducing many incompatible naming convention issues and similar security issues. Regards, Douglas Otis From nobody Mon Jul 20 02:33:03 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F171A0393 for ; Mon, 20 Jul 2015 02:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 BJVfAmcPht2u for ; Mon, 20 Jul 2015 02:33:00 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 C28191A0371 for ; Mon, 20 Jul 2015 02:32:59 -0700 (PDT) Received: by obre1 with SMTP id e1so98365727obr.1 for ; Mon, 20 Jul 2015 02:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=q1Cv3Ta8vEgi2fLNmMv0a+/nfrXxwoguevODIHv4/Zw=; b=rup8U8jzV2SywgWXtAIx0IOmtNYxPG4amjl6d2XiwJCH+VjtJyHfJKwKCToNBftnjq EeZThzU9uupcz1Zz2fBKWxg3/34T0X1UlePI1JkrkL5v+lkq9KOgQYw0iJMylHUX6biy 4T71QkFHmZY34niKLB0oh/EUzrMyQiZWcFcEuZAqgWIWeMFv7oegP83ODtTIEIqVEcR0 +lZZu6oKm/F3y2YE+CPy+wNAZBex8eaYfudiVVaF52R4OsO1KaEzBxJ+xzrNRB+o26QH bIHqA1f8yy9tQxGxoj0oZIAPsBlY7NE6+HNix3328vw/y2Ut9jFh/vZ2W1TwmAYvXtlU zpHw== X-Received: by 10.60.41.138 with SMTP id f10mr24547026oel.84.1437384779135; Mon, 20 Jul 2015 02:32:59 -0700 (PDT) Received: from US-DOUGO-MAC.local (dhcp-b3fa.meeting.ietf.org. [31.133.179.250]) by smtp.googlemail.com with ESMTPSA id f8sm11759309obv.25.2015.07.20.02.32.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 02:32:58 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <55ACC048.9060606@gmail.com> Date: Mon, 20 Jul 2015 11:32:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150708142002.GE58386@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:33:02 -0000 Dear Andrew, We seem to be talking past each other. As such, perhaps going back to the original statements pertaining to your draft might help. On 7/8/15 4:20 PM, Andrew Sullivan wrote: > On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote: >> >> Section 4.3 seems to conflate DNS as always meaning fully >> public global DNS. In the case of mDNS, this is likely not >> the case > > I don't know what you mean by "conflate DNS as always meaning fully > public global DNS". It is true _by definition_ that "the DNS" entails > a single tree with a single root. It's certainly true that you can > arrange things just right so that query-originators to you will see > things that query-originators to other name servers will not see. But > once you've put things in the DNS, any hope that you have that it will > be private -- even in your split-brain arrangements -- are just > wishful thinking. We have learned this over and over again, and I > don't see why it ought to be controversial; I also don't know how it's > relevant here. A split horizon DNS configuration is often used by enterprises, in some cases to override internal queries differentiated through use of ULA prefix or RFC1981 address space as a valid security method to exclude external queries. Such split horizon DNS might be used within local environments as a method to overcome WiFi limitations. There should be no expectation that a locally defined domain conforms with IDNA2008 and does not deserve an out-of-hand dismissal. Security concerns are real and don't require justification. https://tools.ietf.org/html/rfc6950#section-4 > I also don't know what you mean by the second sentence here, since "in > the case of mDNS" is by definition not the public global DNS -- it's a > completely different protocol. This relates to Ambiguous Local Qualified Domain Name (ALQDN) space (see RFC7368), such as .home as suggested by the hybrid draft, or even a domain expressed using UTF-8 label locally recognized (not encoded and without the 'xn--' prefix) can represent locally defined domains that contain sensitive information. As such, the profiles you are attempting to construct might even consider bolstering such exclusions as an element in any developed profile. Again, the general statement made in section 4.3 third sentence: ,-- More important, operators of internationalized domain names will frequently publish such names in the DNS as A-labels; certainly, the top-most labels will always be A-labels. '-- Strike the always be A-Labels assertion and simply state top-most labels in the form of A-Labels can be subject to the profile. Remove any indication that DNS-SD structures contained in a locally defined domain are automatically assumed global. When dealing with locally defined names and their resources resolved using mDNS, these elements may not be suitable for global DNS. >> Change to: >> Operators of internationalized domain names frequently >> publish such names in the DNS as A-labels; these A-labels >> will be subject to the profile. Any namespace not included >> in the profile should be excluded from resolving in a global >> context. > > As I said last time, I don't see what "these A-labels will be subject > to the profile" adds and I find it confusing. Moreover, we _cannot_ > rule out resolution in the DNS "from resolving in a global context". > Here's an example of why. > > As Stuart has pointed out repeatedly, some enterprises already use > DNS-SD in its "wide area" form -- that is, in the DNS. Such a name > might have the following form: > > 3rd Floor Copier Printer.West Wing.example.com > > In a zone file, that is encoded as > > 3rd\ Floor\ Copier\ Printer.West\ Wing.example.com > > The hex encoding of this to the wire format is left as an exercise, > but the key point is that when you query (for instance) the > example.com zone for that you send the entire owner name as the qname > you're trying to look up. Your formulation would prohibit this, and > we heard in previous meetings that the WG explicitly does _not_ want > that, but instead wants a fallback to the DNS-SD (and for that matter > non-IDNA) forms. I think, moreover, that anything that attempts to > insist on formal backward incompatibility is doomed to failure. It seems you misunderstood the objection to your statements regarding absolute assertions of TLDs seen within a local environment. >> Rather than omitting an important consideration, state the >> need for global exclusions. > > But see above. There is not in fact such a need; rather, stating such > a need would be false. >From a security perspective, locally defined domains are needed to implement WiFi remediation techniques where their global exclusion becomes critical at retaining site containment. Demanding conformance with IDNA2008 is counter productive. >> The point missed seems related to risks caused by not >> differentiating local and global namespaces as illustrated >> in the following examples. > > You seem to think that there are "local" and "global" namespaces and > we know which is which in advance. But we don't. That's _exactly_ > the problem. If we knew that in advance, we would know which > resolution system to use, and we would have no issue at all. There are indeed separate global and local namespaces which become critical when relied upon to simplify consideration given to hybrid publications of potentially sensitive information (which might be recognized by their use of local resources and flagged within a profile.) >> It is not clear why mDNS resources moved to DNS > > I don't have any clue what that means. There are no "mDNS resources" > that "move to DNS". Those are different protocols. A hybrid scheme might employ a locally defined TLDs such as .home as a means to avoid use of multicast conveyance expected in .local TLD. A locally defined domain may not always be .home and may not be compliant with IDNA2008 and have the same justification for exceptions for the service names example you have already provided. >> DNS-SD describes a structure intended to be browsed and >> displayed having user friendly encoding. > > Wait. So your issue is that DNS-SD owner names are intended to be > seen by humans? When a domain is locally defined and locally accessible, why not include encoding exceptions with a reasonable strategy how such zones are ascertained? Such a strategy should be part of an Inter op draft, IMHO. >> Tools to browse DNS-SD DO NOT employ encoding used by >> IDNA2008 > > Yes, which is why only the portion is treated as though it > needs to be processed by IDNA. This is mostly because that's where > the names will be in the DNS. Not necessarily. Not when they are locally defined and only locally accessible even if you feel such exclusion can not be reliably achieved. The hybrid approach demands revisiting such a view. > The point of the draft, which I think is explained pretty clearly in > the introduction, is that you'll need the IDNA processing for the > portion or else DNS will just return RCODE 3 and you won't > find what you're looking for. When an access is attempted outside the local environment, an error response is indeed likely and even helpful. > What exactly is "local DNS"? Again, see: https://tools.ietf.org/html/rfc6950#section-4 >> We see the problem differently. There is a real danger >> attempting to combine these two different namespaces, Our differences seem to relate to securing locally defined TLDs such as Ambiguous Local Qualified Domain Name (ALQDN) space referenced in RFC7368. Data leakage resulting from mDNS generated resources is illustrated in the following drafts https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 and https://github.com/chadillac/mdns_recon (Noted in the mDNS Cert notification.) Placing such resources into locally defined and only locally accessible domains could prevent accidental data leakage and move closer to a goal of zero config. Because this is such an important element of the entire mDNS/Hybrid effort, may also mitigate concerns related to: https://tools.ietf.org/html/rfc7558#section-4 REQ15. Regards, Douglas Otis From nobody Mon Jul 20 04:11:38 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459F1A1BB3 for ; Mon, 20 Jul 2015 04:11:36 -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] autolearn=ham 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 q0fscTgn19aq for ; Mon, 20 Jul 2015 04:11:35 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id D96DE1A1B8F for ; Mon, 20 Jul 2015 04:11:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 835BA10012 for ; Mon, 20 Jul 2015 11:11:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5qwFJhXEUQ7 for ; Mon, 20 Jul 2015 11:11:32 +0000 (UTC) Received: from mx2.yitter.info (dhcp-b10d.meeting.ietf.org [31.133.177.13]) by mx2.yitter.info (Postfix) with ESMTPSA id 21DAD10370 for ; Mon, 20 Jul 2015 11:11:31 +0000 (UTC) Date: Mon, 20 Jul 2015 13:11:28 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150720111127.GA22122@mx2.yitter.info> References: <681D46F1-4DCA-442D-946D-AEE7D53C1F68@cisco.com> <20150718202937.GC18337@mx2.yitter.info> <55AB2827.6080003@gmail.com> <20150719072113.GE18688@mx2.yitter.info> <55AB8E0D.302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55AB8E0D.302@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:11:36 -0000 Hi, On Sun, Jul 19, 2015 at 01:46:21PM +0200, Douglas Otis wrote: > > I see mDNS and DNS-SD when populated from a hybrid scheme as > representing the same fruit. You seem to have a category mistake here. DNS and mDNS are both resolution technologies -- two of the ones that can be used with DNS-SD. DNS-SD really just specifies various records, the relevant record formats, and how to interpret the owner name of those records. In DNS-SD, like in SRV, a pattern in the owner name is used as an in-band signal to pack three distinct data into a single message carrier (the owner name). So don't actually understand what it means to say "mDNS and DNS-SD when populated from a hybrid scheme". > to respond with sizable RRsets by design. Responses that > may only be suitable with local exchanges structured to > facilitate service browsing. What are "Responses that may only be suitable with local exchanges"? What is a "local exchange" anyway? > Also, in the case of the hybrid scheme, a TLD of say '.home' > is using Ambiguous Local Qualified Domain Name (ALQDN) space > (see RFC7368). TLDs containing such resources are not held > to common conventions and may allow visual conflicts, for > example. It seems to me that, if you're looking up ALQDNs, you're already out of the DNS. If the service isn't limiting that lookup, isn't there a problem anyway? > As such, a common naming convention may not exist. When a > naming dichotomy is ignored, whether '.home', '.onion', or > perhaps '.domů', resulting incongruities may carry > substantial security risks. Yes. That's an excellent reason to prefer a single global resolution namespace, because unless you're following a single set of rules you run the risk of opening a hole. I think we've established that we want to add some sort of sentence to the security considerations that says that there's some danger in having multiple resolution contexts. But is there something _else_ to say? > A practical solution may demand > a strategy that excludes the majority of mDNS resources > structured as DNS-SD from being directly seen on the > Internet. Establishing guidance to handle very different > name spaces might be seen as a type of profile. That all may well be, but I think it's not what this document is about. You seem to understand that, because it's what you're complaining about, yet you want to change it. But it's as though you're complaining about the cargo-hauling capacity of a sports car: I think if you want what I think you want, you need a different document. I'm not even sure it is a document that belongs in this WG; maybe mif? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 20 07:53:43 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADD71A896A for ; Mon, 20 Jul 2015 07:53:41 -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] autolearn=ham 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 vx9aDb4EL2EY for ; Mon, 20 Jul 2015 07:53:38 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id A77771A8A0E for ; Mon, 20 Jul 2015 07:53:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 3B93410012 for ; Mon, 20 Jul 2015 14:53:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiUQcY_vXlAp for ; Mon, 20 Jul 2015 14:53:37 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2001:67c:370:176:fcf7:b436:4322:f7c2]) by mx2.yitter.info (Postfix) with ESMTPSA id 0BA2910370 for ; Mon, 20 Jul 2015 14:53:35 +0000 (UTC) Date: Mon, 20 Jul 2015 16:53:32 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150720145331.GB659@mx2.yitter.info> References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <55ACC048.9060606@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55ACC048.9060606@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:53:41 -0000 On Mon, Jul 20, 2015 at 11:32:56AM +0200, Douglas Otis wrote: > A split horizon DNS configuration is often used by > enterprises Yes. > space as a valid security method to exclude external No. We know that split horizon systems leak stuff all over the place. There is no reason at all to suppose that names in a split horizon environment successfully keep any name secret. Split horizon is extremely popular snake oil. > queries. Such split horizon DNS might be used within local > environments as a method to overcome WiFi limitations. I don't know what this means. > There should be no expectation that a locally defined domain > conforms with IDNA2008 and does not deserve an out-of-hand > dismissal. There is no expectations that any domain conforms with IDNA2008. There is no protocol rule that DNS names are encoded in any way at all. What we know is that names near the root of the DNS have, as a matter of policy, a restriction on what they'll accept, and it conforms with IDNA. If your argument is that someone with a split horizon has made up for themselves some TLD (say, "corp"), and are sending queries toward that which sometimes leak, well, they're doing the stupidest possible thing you can do in the DNS, which is to make up a name that is not registered and try to use it in the DNS. If such names leak, well, too bad. That's what you get for making up a random name and using it on the global Internet. > This relates to Ambiguous Local Qualified Domain Name > (ALQDN) space (see RFC7368), such as .home as suggested by > the hybrid draft, or even a domain expressed using UTF-8 > label locally recognized (not encoded and without the 'xn--' > prefix) can represent locally defined domains that contain > sensitive information. As such, the profiles you are > attempting to construct might even consider bolstering such > exclusions as an element in any developed profile. No, because the profile that I'm attempting to describe the principles for will _by definition_ produce things that are suitable for the DNS. If what you're saying is that there might be stuff that by policy is just as unlikely to appear in the public DNS near the root as raw UTF-8, then I'm just as happy to refer to it. But excluding the ALQDN won't work, because the ALQDN only works if you can query it somewhere, and this profile is intended to restrict the number of things you can query. > > Again, the general statement made in section 4.3 third sentence: [&c.] I think I already agreed to how this could change, so I'm eliding this part. > Remove any indication that DNS-SD structures contained in a > locally defined domain are automatically assumed global. There is no such assumption. > It seems you misunderstood the objection to your statements > regarding absolute assertions of TLDs seen within a local > environment. What are "TLDs seen within a local environment"? If I do tcpdump on my box, I see lots of .com and .org. I presume that's not what you mean? > There are indeed separate global and local namespaces which Yes, but _we don't know_ in principle which place we're supposed to look something up. If we knew that, we wouldn't need any of this absurd stuff. > expected in .local TLD. A locally defined domain may not > always be .home You don't get to just make up TLDs and configure them locally. I should have thought that Verisign's site finder made this painfully obvious to people, though the experience with home, corp, and mail gives one pause. > When a domain is locally defined and locally accessible, why > not include encoding exceptions with a reasonable strategy > how such zones are ascertained? Because you have no idea whether a domain is "local", however that works, or not. > Our differences seem to relate to securing locally defined > TLDs such as Ambiguous Local Qualified Domain Name (ALQDN) > space referenced in RFC7368. Well, it's hinted at by 7368. It's not actually specified anywhere yet. > Placing such resources into locally defined and only locally > accessible domains There is no such thing as this beast. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 20 10:57:25 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7D1B2F70 for ; Mon, 20 Jul 2015 10:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zZZOlaazlhnz for ; Mon, 20 Jul 2015 10:57:18 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854411B3002 for ; Mon, 20 Jul 2015 10:57:16 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so98624267wib.0 for ; Mon, 20 Jul 2015 10:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ubFkB9XYGZAgOWsINbpM99SwhKwnfGtBfRo+lUFIee4=; b=DW1EnKHcjOYe5oCmEJO32E8eIYERYP7AVXQ9fwUj1I1i03sW3uJY2ykU33vKQjFSm1 vYrKADAQlO/S2r00N5liXWml39LD1u4THF4GwgxWP0g6+fnnV2kmJhKwe2LHcp1BLtD4 FrBA5ktXaxU6W5hC3maHIlhY94QVNhKMjKofKh4Q9dH534fcTT1T1t7P1YQ3mO78Yy9o YUcT9J2ffmPz5MNqeTprTHxpRR+LwNZgvqfw5UPfuxRGlIwlGep0h5o2Z6FsHMbpB/2d AGXXP21Jupgox2CEyALrzBE7OWDpbi25j36ctuL5awP6cP+G4V93G1mn54K3oce/nusk AnOg== X-Received: by 10.194.121.34 with SMTP id lh2mr59206262wjb.101.1437415035258; Mon, 20 Jul 2015 10:57:15 -0700 (PDT) Received: from US-DOUGO-MAC.local (dhcp-b30f.meeting.ietf.org. [31.133.179.15]) by smtp.googlemail.com with ESMTPSA id js3sm33100289wjc.5.2015.07.20.10.57.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 10:57:14 -0700 (PDT) To: dnssd@ietf.org References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <55ACC048.9060606@gmail.com> <20150720145331.GB659@mx2.yitter.info> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <55AD3679.1000003@gmail.com> Date: Mon, 20 Jul 2015 19:57:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150720145331.GB659@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:57:21 -0000 On 7/20/15 4:53 PM, Andrew Sullivan wrote: > On Mon, Jul 20, 2015 at 11:32:56AM +0200, Douglas Otis wrote: >> A split horizon DNS configuration is often used by >> enterprises > > Yes. > >> space as a valid security method to exclude external > > No. We know that split horizon systems leak stuff all over the place. > There is no reason at all to suppose that names in a split horizon > environment successfully keep any name secret. Split horizon is > extremely popular snake oil. Dear Andrew, The concern is to isolate specific resources held within locally defined domains. Indeed these names may be sent to external resolvers. Nevertheless, such "leakage" does not makes a split horizon technique invalid, IMHO. >> queries. Such split horizon DNS might be used within local >> environments as a method to overcome WiFi limitations. > > I don't know what this means. mDNS resources are being moved into a locally defined DNS TLDs to avoid the use of .local that implies an expectation of mDNS resolution. In other words, use of potentially harmful levels of multicast traffic. >> There should be no expectation that a locally defined domain >> conforms with IDNA2008 and does not deserve an out-of-hand >> dismissal. > > There is no expectations that any domain conforms with IDNA2008. > There is no protocol rule that DNS names are encoded in any way at > all. What we know is that names near the root of the DNS have, as a > matter of policy, a restriction on what they'll accept, and it > conforms with IDNA. Agreed, but why expect there will be local policy to enforce IDNA2008 compliance? As you suggested, there is also an advantage when those outside the split horizon receive an error. > If your argument is that someone with a split horizon has made up for > themselves some TLD (say, "corp"), and are sending queries toward that > which sometimes leak, well, they're doing the stupidest possible thing > you can do in the DNS, which is to make up a name that is not > registered and try to use it in the DNS. If such names leak, well, > too bad. That's what you get for making up a random name and using it > on the global Internet. The concern is not with the names, but with resources associated with the services. We both agree global DNS services should respond with an error instead of the desired resources. A good thing. >> This relates to Ambiguous Local Qualified Domain Name >> (ALQDN) space (see RFC7368), such as .home as suggested by >> the hybrid draft, or even a domain expressed using UTF-8 >> label locally recognized (not encoded and without the 'xn--' >> prefix) can represent locally defined domains that contain >> sensitive information. As such, the profiles you are >> attempting to construct might even consider bolstering such >> exclusions as an element in any developed profile. > > No, because the profile that I'm attempting to describe the principles > for will _by definition_ produce things that are suitable for the DNS. Your view suggests there is NO value isolating locally defined domains using split horizon DNS or perhaps a BTMM scheme although this seems to represent what is meant by ALQDN. The requested change was to not have your view implied in this draft and the reason for the change requested. A domain where resources are only available when within a split horizon can be enforced by only responding when client addresses are also site local. Yes, query names will leak. Again, some desire having a zero-config scheme where this technique comes fairly close and offers better protection for that approach. Nothing is perfect. > If what you're saying is that there might be stuff that by policy is > just as unlikely to appear in the public DNS near the root as raw > UTF-8, then I'm just as happy to refer to it. But excluding the ALQDN > won't work, because the ALQDN only works if you can query it > somewhere, and this profile is intended to restrict the number of > things you can query. If you are willing to make this this statement, then why insist all TLDs must use A-Labels? Just remove this statement and remain silent about what is or is not allowed within locally resolved TLDs. ALQDN will work within a network offering a split horizon based on some type of scheme. >> Again, the general statement made in section 4.3 third sentence: > > [&c.] I think I already agreed to how this could change, so I'm > eliding this part. > >> Remove any indication that DNS-SD structures contained in a >> locally defined domain are automatically assumed global. > > There is no such assumption. The statement made regarding the use of A-labels below all TLDs IS making this assumption in my view. >> It seems you misunderstood the objection to your statements >> regarding absolute assertions of TLDs seen within a local >> environment. > > What are "TLDs seen within a local environment"? If I do tcpdump on > my box, I see lots of .com and .org. I presume that's not what you > mean? No. Locally defined domains not found in global DNS. One method might make use of .home as defined in the hybrid draft or perhaps a UTF-8 label lacking the 'xn--' prefix to be friendly for those not using ASCII where entering .home is not practical. >> There are indeed separate global and local namespaces which > > Yes, but _we don't know_ in principle which place we're supposed to > look something up. If we knew that, we wouldn't need any of this > absurd stuff. It seems there is also little desire to implement IDNA2008 encoding for locally defined resources as well. >> expected in .local TLD. A locally defined domain may not >> always be .home > > You don't get to just make up TLDs and configure them locally. I > should have thought that Verisign's site finder made this painfully > obvious to people, though the experience with home, corp, and mail > gives one pause. A split horizon DNS scheme should override and prevent ill considered redirection to "partner" sites. >> When a domain is locally defined and locally accessible, why >> not include encoding exceptions with a reasonable strategy >> how such zones are ascertained? > > Because you have no idea whether a domain is "local", however that > works, or not. The local DNS resolver knows and resolves resources properly which provides a way of knowing. >> Our differences seem to relate to securing locally defined >> TLDs such as Ambiguous Local Qualified Domain Name (ALQDN) >> space referenced in RFC7368. > > Well, it's hinted at by 7368. It's not actually specified anywhere > yet. > >> Placing such resources into locally defined and only locally >> accessible domains > > There is no such thing as this beast. We seem to consider the validity of various techniques supporting uniquely resolved local domains differently, such as that defined in RFC6281. Many many hold that scheme in high regard. Regards, Douglas Otis From nobody Tue Jul 21 01:08:52 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86251B29C0 for ; Tue, 21 Jul 2015 01:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Pt4zq6V5iW3U for ; Tue, 21 Jul 2015 01:06:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909621AD373 for ; Tue, 21 Jul 2015 01:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=435; q=dns/txt; s=iport; t=1437465971; x=1438675571; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=tGmbFSqWdtrk2mGlD7ik4ctAC6zd1rEnfZf/VRWtBdY=; b=UE+U07aBg0p6XCqPU/Mi11+3sqKWmntOY4Gx/j+BGPA7Id/d1lB2ELeP bPKnyDsY0Nt9G/WGIQdLV2tGUXHDqergqMV+KIjjldjRQNGZUCRbhGr3+ tyCnP40YQXOojL5SVxi7CIt2QV9LWoW2cvSbTonYujnQadhXW9X85Vf2T w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiAwA9/K1V/5pdJa1cgxOBPQa7fQmJKjgUAQEBAQEBAYEKhCo6UQE+QicEE4guo1OmMAEBAQEGAQEBAQEBARuLTIgkgRQFlFMBjCmBQ4Qcj06DYSaDfG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="170589601" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 21 Jul 2015 08:06:10 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6L86ALt006472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jul 2015 08:06:10 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.109]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 03:06:10 -0500 From: "Ralph Droms (rdroms)" To: "dnsop@ietf.org" Thread-Topic: Requesting review of draft-ietf-dnssd-mdns-dns-interop-01 Thread-Index: AQHQw4waxvLGHd9kJUOvL8JnRaZGRw== Date: Tue, 21 Jul 2015 08:06:10 +0000 Message-ID: <73AE272C-AC40-434D-AB42-9E09A1CD9557@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.86] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2015 01:08:51 -0700 Subject: [dnssd] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:06:12 -0000 Hi - The dnssd chairs would like to get some reviews of draft-ietf-dnssd-md= ns-dns-interop-01, "On Interoperation of Labels Between mDNS and DNS," from= dnsop participants. draft-ietf-dnssd-mdns-dns-interop-01 is currently in = dnssd WG last call and last call comments will be discussed in the dnssd WG= meeting this week.=20 Please post your feedback to dnsop or send to Tim and myself. - Ralph Bcc: dnssd@ietf.org From nobody Tue Jul 21 09:17:40 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8E21B2FA3 for ; Tue, 21 Jul 2015 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 6VdhyOvJmwOL for ; Tue, 21 Jul 2015 09:17:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81B81B2FA1 for ; Tue, 21 Jul 2015 09:17:35 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t6LGGCKG003640; Tue, 21 Jul 2015 17:16:12 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t6LGGCKG003640 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1437495372; bh=03uNMLQNFtOYBHmz3t8suXrrUTo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=NgN6VQm3podwaV9QZZYsHN/JVDbYBTvWinBbVidfgf/FTkyIBtQAbooQ47cUxivCb IyTYwQhW5WEpI50SQQlbxDy01T+oLVzeLA4yVkvtZAHiIGL/qVgmJ6qCuaG73Xm7aD nylw4mKTnIMspmc/fzgY3q/2Brlt63EPF9K6T0Dc= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r6KHGC0996407514U2 ret-id none; Tue, 21 Jul 2015 17:16:12 +0100 Received: from [IPv6:2001:67c:370:152:3891:6e19:89fd:12c5] ([IPv6:2001:67c:370:152:3891:6e19:89fd:12c5]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t6LGG7TF010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2015 17:16:07 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_C34AD43C-5349-4CA0-A966-0A973E63F431" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Chown In-Reply-To: <55AA52BA.4040909@gmail.com> Date: Tue, 21 Jul 2015 17:16:26 +0100 Message-ID: References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <559DDE7E.7050201@gmail.com> <20150717162702.GI14702@crankycanuck.ca> <55AA52BA.4040909@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2102) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r6KHGC099640751400; tid=r6KHGC0996407514U2; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t6LGGCKG003640 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:17:38 -0000 --Apple-Mail=_C34AD43C-5349-4CA0-A966-0A973E63F431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Doug, > On 18 Jul 2015, at 14:20, Douglas Otis wrote: >=20 > ... >=20 > The chartered goal was largely aimed at solving Apple's > connectivity issues within school environments. Satisfying > such a goal should be met while also not exposing hybrid > resources to the Internet or while strictly moderating the > amount of mDNS resources exposed. > =E2=80=A6 I=E2=80=99ve listened to the recent exchange between yourself and = Andrew, and while I feel you have raised some valid points, I don=E2=80=99= t see that they are addressing the core topic being discussed in this = draft, which is interoperability between labels used in different naming = systems, as the title and name of the draft very clearly states. On that basis, I don=E2=80=99t see any specific valid issues being = raised against the content of this document. There have been no other = issues raised during WGLC. Ralph and I are also discussing the draft = with the dnsop chairs, with a view to ensuring appropriate review has = been given from that WG. Having said that, I believe you are asking some valid questions about = the threat model of the hybrid DNS approach, including: a) potential for use in DDoS attack b) leakage of information (though wide area DNS-SD is possible in one = form already now as Stuart has demonstrated in previous meetings) c) scope of addressing being used What I encourage is that you discuss these with Hosnieh, as author of = the (currently personal) threat draft, see: https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03 = You=E2=80=99ll see that section 3.5 talk about leakage, for example.=20 Ralph and I would like to see the WG agree on the key areas for this = draft to cover, with a view to adoption as a WG item, so that will be a = focus in Wednesday=E2=80=99s session, and subsequently on the list here. As a final point, while the Educause petition was one driver for the = dnssd WG work, there are five scenarios under consideration, including = unmanaged home networks, for example. Tim --Apple-Mail=_C34AD43C-5349-4CA0-A966-0A973E63F431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Doug,

On 18 Jul 2015, at 14:20, = Douglas Otis <doug.mtview@gmail.com> wrote:

...

The chartered goal was = largely aimed at solving Apple's
connectivity issues = within school environments.  Satisfying
such a goal = should be met while also not exposing hybrid
resources to = the Internet or while strictly moderating the
amount of = mDNS resources exposed.

=E2=80=A6

I=E2=80=99ve listened to the = recent exchange between yourself and Andrew, and while I feel you have = raised some valid points, I don=E2=80=99t see that they are addressing = the core topic being discussed in this draft, which is interoperability = between labels used in different naming systems, as the title and name = of the draft very clearly states.

On that basis, I don=E2=80=99t see any = specific valid issues being raised against the content of this document. = There have been no other issues raised during WGLC. Ralph and I are also = discussing the draft with the dnsop chairs, with a view to ensuring = appropriate review has been given from that WG.

Having said that, I believe you are = asking some valid questions about the threat model of the hybrid DNS = approach, including:
a) potential for use in DDoS = attack
b) leakage of information (though wide area = DNS-SD is possible in one form already now as Stuart has demonstrated in = previous meetings)
c) scope of addressing being = used

What I = encourage is that you discuss these with Hosnieh, as author of the = (currently personal) threat draft, see:
https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel= -03

You=E2=80= =99ll see that section 3.5 talk about leakage, for = example. 

Ralph and I would like to see the WG agree on the key areas = for this draft to cover, with a view to adoption as a WG item, so that = will be a focus in Wednesday=E2=80=99s session, and subsequently on the = list here.

As = a final point, while the Educause petition was one driver for the dnssd = WG work, there are five scenarios under consideration, including = unmanaged home networks, for example.

Tim

= --Apple-Mail=_C34AD43C-5349-4CA0-A966-0A973E63F431-- From nobody Tue Jul 21 09:27:48 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E11A9062 for ; Tue, 21 Jul 2015 09:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 MgjxzopyeGYW for ; Tue, 21 Jul 2015 09:27:45 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C951A8F4E for ; Tue, 21 Jul 2015 09:27:44 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t6LGRhxZ006227 for ; Tue, 21 Jul 2015 17:27:43 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t6LGRhxZ006227 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1437496063; bh=jmFo09+shtn+n27uethADGDbjO8=; h=From:Subject:Date:To:Mime-Version:References; b=R0BpNoKhdAwWUn9QJJ0beRs9Nk58MXdOZBDdfWOjAlwnEx7kHNqpz4TDFwukmW1QJ wou9Yo5tl/kMuyZUm+mqqqKQoFNRbJGmuyznJkOm/OYpneJSttHhCLTHAzCtXdD+g3 BW+j+vCcJ6y/ZPNMwYHIATugEuXmV8pyNyhRt7/0= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r6KHRh0996407600Yi ret-id none; Tue, 21 Jul 2015 17:27:43 +0100 Received: from [IPv6:2001:67c:370:152:3891:6e19:89fd:12c5] ([IPv6:2001:67c:370:152:3891:6e19:89fd:12c5]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t6LGQNSn012755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jul 2015 17:26:24 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_B8BDD8C7-1DAB-4693-A5ED-83A627059AFF" Message-ID: Date: Tue, 21 Jul 2015 17:26:43 +0100 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r6KHRh099640760000; tid=r6KHRh0996407600Yi; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <9DA1FEB8-3546-4F23-85D0-6A712B6A0BD6@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t6LGRhxZ006227 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: [dnssd] draft-rafiee-dnssd-mdns-threatmodel-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:27:46 -0000 --Apple-Mail=_B8BDD8C7-1DAB-4693-A5ED-83A627059AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Following on from the previous email, I=E2=80=99d like to encourage = discussion of draft-rafiee-dnssd-mdns-threatmodel-03. See: https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03 = Hosnieh has pulled together this draft in response to a request from = Ralph and I as chairs. We=E2=80=99d like to see the WG discuss and agree = on the scope of the threats that we cover in this document, with a view = to adopting it as a WG item. And specifically to Doug - you have raised points previously on DDoS = attack paths, information leakage, and address scopes (esp. ULA). It = would be good to articulate these more precisely, and to determine where = they might fit into the structure of the draft as it stands. I can see = Hosnieh already has DoS (section 3.2) and Leakage (section 3.5) = included. A reminder that a the goal of the WG is to enable scalable, wide area = service discovery, across multiple links. There is thus a natural = trade-off in convenience, and the ability to discover remote services, = and information exposure.=20 My personal feeling is that the document should focus on specific = threats related to the new extended DNS-SD model that the hybrid pray = model introduces; thus we could probably shrink or even remove 3.9, and = focus on the earlier sections of the document. But this is what we=E2=80=99= d like the WG to give input on. Ralph and I will also seek opsec input on this document. We would also = welcome input from homenet, where Markus and others have been developing = methods to have a hybrid proxy model run autonomously, though - as yet - = there isn=E2=80=99t a specific homenet threat model document. Tim --Apple-Mail=_B8BDD8C7-1DAB-4693-A5ED-83A627059AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Following on from the previous email, I=E2=80=99d like to = encourage discussion of draft-rafiee-dnssd-mdns-threatmodel-03.
See: https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel= -03

Hosnieh = has pulled together this draft in response to a request from Ralph and I = as chairs. We=E2=80=99d like to see the WG discuss and agree on the = scope of the threats that we cover in this document, with a view to = adopting it as a WG item.

And specifically to Doug - you have raised points previously = on DDoS attack paths, information leakage, and address scopes (esp. = ULA). It would be good to articulate these more precisely, and to = determine where they might fit into the structure of the draft as it = stands. I can see Hosnieh already has DoS (section 3.2) and Leakage = (section 3.5) included.

A reminder that a the goal of the WG is to enable scalable, = wide area service discovery, across multiple links. There is thus a = natural trade-off in convenience, and the ability to discover remote = services, and information exposure. 

My personal feeling is that the = document should focus on specific threats related to the new extended = DNS-SD model that the hybrid pray model introduces; thus we could = probably shrink or even remove 3.9, and focus on the earlier sections of = the document. But this is what we=E2=80=99d like the WG to give input = on.

Ralph and = I will also seek opsec input on this document. We would also welcome = input from homenet, where Markus and others have been developing methods = to have a hybrid proxy model run autonomously, though - as yet - there = isn=E2=80=99t a specific homenet threat model document.

Tim

= --Apple-Mail=_B8BDD8C7-1DAB-4693-A5ED-83A627059AFF-- From nobody Tue Jul 21 11:40:24 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8811ACD71 for ; Tue, 21 Jul 2015 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 meYdN2G80YVv for ; Tue, 21 Jul 2015 11:40:20 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 427101ACD63 for ; Tue, 21 Jul 2015 11:40:20 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 1D99E25CA2AE; Tue, 21 Jul 2015 18:40:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot-8TiQ2yLsa; Tue, 21 Jul 2015 20:40:16 +0200 (CEST) Received: from kopoli (p200300864F13D18A80731F0F5437F99A.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d18a:8073:1f0f:5437:f99a]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 017BC25CA0BF; Tue, 21 Jul 2015 20:40:15 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Douglas Otis'" References: <20150530185803.18524.17824.idtracker@ietfa.amsl.com> <814D0BFB77D95844A01CA29B44CBF8A70154C4DA@lhreml504-mbs> <556E6936.1070205@gmail.com> In-Reply-To: <556E6936.1070205@gmail.com> Date: Tue, 21 Jul 2015 20:40:14 +0200 Message-ID: <03b001d0c3e4$aefadba0$0cf092e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCrwxXFLzi2goKxFti+g9RA1FjdJAH2O5pYAnR+Q1egDOKZcA== Content-Language: en-us Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-rafiee-dnssd-mdns-threatmodel-03.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 18:40:23 -0000 Hi Douglas, Sorry, I guess I overlooked this message and just saw it now.. > > > On 6/1/15 12:18 AM, Hosnieh Rafiee wrote: > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03 > Dear Hosnieh, > > This review misses a concern called out in the CERT notice for dnssd at > https://www.kb.cert.org/vuls/id/550620 Yes, right. I have another type of this attack in http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3. 4.1 I will add another subsection under 3.5 which is about privacy issues with the following text Mixing unicast names and multicast names A service might respond to unicast queries that originated from sources outside of the local link network. Such responses may disclose information and harm the privacy about users of that network For the DoS part of that I already have a section here http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3. 2 Does it work for you? > See Section 1 of > https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06 > > The threat model also overlooks data leakage beyond a local link and DNS > amplification concerns resulting from the browse-ability offered by resource > structures as explained in the introduction and the CERT notice. That is right that I do not have it as DNS amplification but only under the title DoS attack I am not sure it is necessary but I can add a subsection under DoS attack with the following text DNS amplification attack Since a service might also response to unicast queries outside of its local link, then an attacker might be able to learn the IP address of this service and sends a lot of queries to a unicast DNS with the spoofed source IP address of this service which result in DNS amplification attack on the victim service and make this service unavailable to the service requesters, that is, lead to a DoS attack. Does it work for you? > Appendix A gives an example of data leakage exploited in Appendix B. > > A mitigation practice to overcome these risks remains unclear unless some > means is made available to limit results. Mitigation might be the Response Rate limit (RRL) as there was discussion in other WG on the unicast DNS server as well as this service. Then after receiving the same request from the same source IP, it just discards rest of the messages. Is there anything else that needs to be considered in the document. I am going to add it to the offline of the document and if there is no more comments, I can submit the new version. Thanks, Best, Hosnieh P.S. That is fine for me to receive two copy of a same message because I might overlook messages that I am not in CC or To. thanks From nobody Tue Jul 21 22:43:32 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1D1ACCF8; Tue, 21 Jul 2015 22:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8RfmWTUpHo8v; Tue, 21 Jul 2015 22:43:28 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 C9ABE1ACCEB; Tue, 21 Jul 2015 22:43:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 260E525CA2AE; Wed, 22 Jul 2015 05:43:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTTwV7-UQd3o; Wed, 22 Jul 2015 07:43:24 +0200 (CEST) Received: from kopoli (p200300864F13D155718B951C5C0ED2EF.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d155:718b:951c:5c0e:d2ef]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id DFBA125CA0C0; Wed, 22 Jul 2015 07:43:23 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Wed, 22 Jul 2015 07:43:21 +0200 Message-ID: <003b01d0c441$52043470$f60c9d50$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDEQVFJFIHGft/mSFW37rCzAl65XA== Content-Language: en-us Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 05:43:30 -0000 Hello, I reviewed this draft. to be clear, I am not expert in unicode or internationalized charactersets. My comments are as followings: I think there is attack on the interopration of mDNS and unicast DNS and I think applicable to this draft while in the security consideration, it is not mentioned any mitigation mechanism. - mixing mDNS and unicast DNS names poor implementation might allow an attacker to response to unicast DNS query request sent by a client for the purpose of resolving a global domain name. If the mDNS requests are prioterize, there is a possibility that the client accepts the mDNS response and prioterize it over unicast DNS names. Therefore, the attacker has a chance to offer a fake response . The risk of this attack is higher when the internationalized character set is allowed in unicast DNS server. The possible mitigation is authentication of a service as well as the unicast DNS Now the question is that is it possible also to cheat the recursive resolver with mDNS responses while looking up for a domain? If the priority for looking up names is first unicast DNS and then mDNS, then in this case there might be a lot of traffic to unicast DNS servers and if it is the other round, then there might be the possibility of the attack mentioned above mitigation: authentication of recursive resolver - section 3 U-labels cannot contain upper case letters For some languages, upper case letter does not make it different specially in some letters. Especially the languages that a word is the result of attaching the characters together. I think this is specially true for non-european languages. Two examples are Persian or Arabic. Therefore, one cannot differentiate between mDNS service and DNS names with only considering that DNS cannot use uppercase U-labels. - section 4.2 It is not the requirement of DNSSD to use underscoll character, as far as I can see it is only recommendation. please see https://tools.ietf.org/html/rfc6763#section-7 Therefore, the attacker can use the similar domain names as unicast DNS for its fake service which might result in confusion of the recursive DNS servers Thanks, Best, Hosnieh > -----Original Message----- > From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Ralph Droms > (rdroms) > Sent: Tuesday, July 21, 2015 10:06 AM > To: dnsop@ietf.org > Subject: [dnssd] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01 > > Hi - The dnssd chairs would like to get some reviews of draft-ietf-dnssd-mdns- > dns-interop-01, "On Interoperation of Labels Between mDNS and DNS," from > dnsop participants. draft-ietf-dnssd-mdns-dns-interop-01 is currently in dnssd > WG last call and last call comments will be discussed in the dnssd WG meeting > this week. > > Please post your feedback to dnsop or send to Tim and myself. > > - Ralph > > Bcc: dnssd@ietf.org > From nobody Wed Jul 22 00:06:26 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69AA1ACDE4 for ; Wed, 22 Jul 2015 00:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qpJHp8QmEuJj for ; Wed, 22 Jul 2015 00:06:23 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDA31ACE19 for ; Wed, 22 Jul 2015 00:06:02 -0700 (PDT) Received: by oige126 with SMTP id e126so138157987oig.0 for ; Wed, 22 Jul 2015 00:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=O+qNzhJNuZAggmaE8st6dNcw9cm7IWKMGeN9PbWiwyM=; b=MSLChLAGRKWffM3vPKK4DQQjtaCJg7GT+MYGk7DAeisZnMgTbKQ1cpbnGk4Rh2nBpc UKcBx6d7Zz7gqqpKq+rToEqMfTlEQfAmuF8FJWV/bUgE9pRgwpJMQC+ogA5RSQKztLzH o2DHUEKxow6LUmwpbkFLvte/qO0i7UZHFpZDQkz6R40Rsaz5v6+jZ0oPLAa/OMaKTpD0 v0bvD+ioKmtQqoUntWb6MegsdBH7KJeQvy+XM0LLVvV3yB76xV2NW4YLZaEr57aEkIqe PqE28iTbdBmdx5cLf+tfsF5tuM5gm3i75SgOf7gDDM+DTNUxJbZRPZ5odpF9Qau4W33+ WwCw== X-Received: by 10.202.80.216 with SMTP id e207mr888470oib.116.1437548762083; Wed, 22 Jul 2015 00:06:02 -0700 (PDT) Received: from US-DOUGO-MAC.local ([2001:67c:370:176:1c1e:8602:a193:5815]) by smtp.googlemail.com with ESMTPSA id yo9sm335200obc.3.2015.07.22.00.06.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 00:06:01 -0700 (PDT) To: Tim Chown References: <20150704212511.22803.60661.idtracker@ietfa.amsl.com> <20150705002321.GB48722@mx2.yitter.info> <559B2A77.9030606@gmail.com> <20150707024239.GC52436@mx2.yitter.info> <559C83C1.9070103@gmail.com> <20150708024330.GA55186@mx2.yitter.info> <559CD5D9.4030000@gmail.com> <20150708142002.GE58386@mx2.yitter.info> <559DDE7E.7050201@gmail.com> <20150717162702.GI14702@crankycanuck.ca> <55AA52BA.4040909@gmail.com> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <55AF40DA.7010502@gmail.com> Date: Wed, 22 Jul 2015 09:06:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:06:24 -0000 Dear Tim, I agree with your statements. The other issue being raised related to the topic based on a poor history of special domain assignment especially as related to IDNA. Dave Thaler convinced me conventions can be established to automate inclusion of the "special" domain such as '.home'. Based on that view, I'll be happy to withdraw the request related to TLDs. Regards, Douglas Otis On 7/21/15 6:16 PM, Tim Chown wrote: > Hi Doug, > >> On 18 Jul 2015, at 14:20, Douglas Otis wrote: >> >> ... >> >> The chartered goal was largely aimed at solving Apple's >> connectivity issues within school environments. Satisfying >> such a goal should be met while also not exposing hybrid >> resources to the Internet or while strictly moderating the >> amount of mDNS resources exposed. > >> … > > > I’ve listened to the recent exchange between yourself and Andrew, and while I feel you have raised some valid points, I don’t see that they are addressing the core topic being discussed in this draft, which is interoperability between labels used in different naming systems, as the title and name of the draft very clearly states. > > On that basis, I don’t see any specific valid issues being raised against the content of this document. There have been no other issues raised during WGLC. Ralph and I are also discussing the draft with the dnsop chairs, with a view to ensuring appropriate review has been given from that WG. > > Having said that, I believe you are asking some valid questions about the threat model of the hybrid DNS approach, including: > a) potential for use in DDoS attack > b) leakage of information (though wide area DNS-SD is possible in one form already now as Stuart has demonstrated in previous meetings) > c) scope of addressing being used > > What I encourage is that you discuss these with Hosnieh, as author of the (currently personal) threat draft, see: > https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03 > > You’ll see that section 3.5 talk about leakage, for example. > > Ralph and I would like to see the WG agree on the key areas for this draft to cover, with a view to adoption as a WG item, so that will be a focus in Wednesday’s session, and subsequently on the list here. > > As a final point, while the Educause petition was one driver for the dnssd WG work, there are five scenarios under consideration, including unmanaged home networks, for example. > > Tim > > From nobody Wed Jul 22 01:36:27 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBC1ACEB6 for ; Wed, 22 Jul 2015 01:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 jVMXik0rA7J2 for ; Wed, 22 Jul 2015 01:36:20 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id A559A1ACEB4 for ; Wed, 22 Jul 2015 01:36:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 4E19D105DD for ; Wed, 22 Jul 2015 08:36:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlirW6Qr5nb1 for ; Wed, 22 Jul 2015 08:36:07 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2001:67c:370:176:9131:64fb:b2b1:b71c]) by mx2.yitter.info (Postfix) with ESMTPSA id 1F2C210370 for ; Wed, 22 Jul 2015 08:36:07 +0000 (UTC) Date: Wed, 22 Jul 2015 10:36:05 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150722083604.GF4832@mx2.yitter.info> References: <003b01d0c441$52043470$f60c9d50$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <003b01d0c441$52043470$f60c9d50$@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:36:23 -0000 Hi, On Wed, Jul 22, 2015 at 07:43:21AM +0200, Hosnieh Rafiee wrote: > > - mixing mDNS and unicast DNS names […] > Now the question is that is it possible also to cheat the recursive resolver > with mDNS responses while looking up for a domain? No. As I said in the WG session, the way that mDNS and DNS differentiate is using an in-band signalling mechanism, which is the final non-null label of the QNAME. If that last non-null label is local, then it's mDNS; otherwise, it isn't. If mDNS is responding to DNS queries, then it's just not following the mDNS protocol. > - section 3 > U-labels cannot contain upper case letters > > For some languages, upper case letter does not make it different specially > in some letters. Especially the languages that a word is the result of > attaching the characters together. I think this is specially true for > non-european languages. Two examples are Persian or Arabic. > > Therefore, one cannot differentiate between mDNS service and DNS names with > only considering that DNS cannot use uppercase U-labels. Indeed, you cannot, and the document does not suggest you use this mechanism to tell whether something is a DNS name, right? > - section 4.2 > It is not the requirement of DNSSD to use underscoll character, as far as I > can see it is only recommendation. I don't see how. The text you cite starts thus: The portion of a Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782]. The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it. The underscore character is in fact part of the definition, and is the only way AFAICT that you'd be able to tell which part of the owner name is the portion of a Service Instance Name. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 22 01:51:17 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2E81A8A3C for ; Wed, 22 Jul 2015 01:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QMZ4SWSdDoiK for ; Wed, 22 Jul 2015 01:51:13 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 6F5F81ACEA5 for ; Wed, 22 Jul 2015 01:51:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id B79FB25CA2AE for ; Wed, 22 Jul 2015 08:51:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TYFgfEoQKid for ; Wed, 22 Jul 2015 10:51:04 +0200 (CEST) Received: from kopoli (p200300864F13D155718B951C5C0ED2EF.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d155:718b:951c:5c0e:d2ef]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 9FEA125CA0C0 for ; Wed, 22 Jul 2015 10:51:04 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <003b01d0c441$52043470$f60c9d50$@rozanak.com> <20150722083604.GF4832@mx2.yitter.info> In-Reply-To: <20150722083604.GF4832@mx2.yitter.info> Date: Wed, 22 Jul 2015 10:51:02 +0200 Message-ID: <00ac01d0c45b$89f49540$9dddbfc0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDvsKtGOwvciL+TIXR7yt5OsERRRAJS6gkIn5a93NA= Content-Language: en-us Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:51:15 -0000 Hi Andrew, >=20 > [=E2=80=A6] >=20 > > Now the question is that is it possible also to cheat the recursive > > resolver with mDNS responses while looking up for a domain? >=20 > No. As I said in the WG session, the way that mDNS and DNS = differentiate is > using an in-band signalling mechanism, which is the final non-null = label of the > QNAME. If that last non-null label is local, then it's mDNS; = otherwise, it isn't. If > mDNS is responding to DNS queries, then it's just not following the = mDNS > protocol. >=20 > > - section 3 > > U-labels cannot contain upper case letters > > > > For some languages, upper case letter does not make it different > > specially in some letters. Especially the languages that a word is = the > > result of attaching the characters together. I think this is > > specially true for non-european languages. Two examples are Persian = or > Arabic. > > > > Therefore, one cannot differentiate between mDNS service and DNS = names > > with only considering that DNS cannot use uppercase U-labels. >=20 > Indeed, you cannot, and the document does not suggest you use this > mechanism to tell whether something is a DNS name, right? True > > - section 4.2 > > It is not the requirement of DNSSD to use underscoll character, as = far > > as I can see it is only recommendation. >=20 > I don't see how. The text you cite starts thus: This part which says its is not a requirement of SRV records in general. = What I understand is that following this structure is not the = requirements. They are free to specify their namings Note that this usage of the "_udp" label for all protocols other than TCP applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. Other specifications that are independent of DNS-SD and not intended to interoperate with DNS-SD records are not in any way constrained by how DNS-SD works just because they also use the DNS SRV record datatype [RFC2782]; they are free to specify their own naming conventions as appropriate. > The portion of a Service Instance Name consists of a pair > of DNS labels, following the convention already established for SRV > records [RFC2782]. >=20 > The first label of the pair is an underscore character followed by > the Service Name [RFC6335]. The Service Name identifies what the > service does and what application protocol it uses to do it. >=20 > The underscore character is in fact part of the definition, and is the = only way > AFAICT that you'd be able to tell which part of the owner name is the > portion of a Service Instance Name. >=20 > Best regards, >=20 Thanks, Best, Hosnieh From nobody Wed Jul 22 01:55:45 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64291ACE5C for ; Wed, 22 Jul 2015 01:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 FpADT6CpnBbJ for ; Wed, 22 Jul 2015 01:55:43 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2E1ACE97 for ; Wed, 22 Jul 2015 01:55:42 -0700 (PDT) Received: from [192.168.43.129] (80.220.64.126) by kirsi2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF6A00F33217 for dnssd@ietf.org; Wed, 22 Jul 2015 11:55:41 +0300 From: Markus Stenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 22 Jul 2015 10:55:39 +0200 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [dnssd] My (slightly updated) notes on draft-ietf-dnssd-hybrid-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:55:44 -0000 (in order of importance; I did these in case I had to talk about it in = dnssd..) ** S 3.2 MUST -> SHOULD, and I agree, but if I e.g. autogenerate domain names, rather use LDH domain names for services too. ** S 3.5 - no LLQ -> 'three times' is highly suspicious - also, it does not specify what delay for the 3 times (or how to wait = for final reply) =20 - can results be given before all 3 are completed? unclear, but e.g. CF and non-CF should behave differently here IMO my recommendation (abd what we have implemented): - send once - return CF result immediately if it comes - otherwise return 'after implementation-specific delay' ** S 3.4.1 I consider 10 sec TTL bit low; no experimental results to back it up. As = it is a SHOULD, no big deal. ** S (meta) LLQ =3D> push (I would rather wait for push to be referrable than = publish as is) ** (impl) - 2 years since my first implementation of this actually worked (in = Berlin summer IETF) - NO change to our impl logic (although some might be argued for) since, = I think, although there was one re-implementation effort in the middle (Lua->C). Cheers, -Markus= From nobody Wed Jul 22 03:06:14 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92881ACD25 for ; Wed, 22 Jul 2015 03:06: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] autolearn=ham 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 JCOrjf0Rc6Iw for ; Wed, 22 Jul 2015 03:06:11 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5F1ACD3C for ; Wed, 22 Jul 2015 03:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id C2C631036F for ; Wed, 22 Jul 2015 10:06:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ape5NgvH_1Wd for ; Wed, 22 Jul 2015 10:06:09 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2001:67c:370:176:9927:30ac:cbc2:99a8]) by mx2.yitter.info (Postfix) with ESMTPSA id D26A010370 for ; Wed, 22 Jul 2015 10:06:08 +0000 (UTC) Date: Wed, 22 Jul 2015 12:06:04 +0200 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150722100604.GI4832@mx2.yitter.info> References: <003b01d0c441$52043470$f60c9d50$@rozanak.com> <20150722083604.GF4832@mx2.yitter.info> <00ac01d0c45b$89f49540$9dddbfc0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ac01d0c45b$89f49540$9dddbfc0$@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 10:06:12 -0000 On Wed, Jul 22, 2015 at 10:51:02AM +0200, Hosnieh Rafiee wrote: > > This part which says its is not a requirement of SRV records in general. What I understand is that following this structure is not the requirements. They are free to specify their namings I think you have it backwards. I believe the text you cite is saying that DNS-SD is not making normative rules for all SRV records, just for ones in use for DNS-SD. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 22 03:06:50 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4A1AD0CF for ; Wed, 22 Jul 2015 03:06:49 -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] autolearn=ham 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 sbC6ugvJDCcp for ; Wed, 22 Jul 2015 03:06:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF1F1ACD3E for ; Wed, 22 Jul 2015 03:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150722100647.9447.28871.idtracker@ietfa.amsl.com> Date: Wed, 22 Jul 2015 03:06:47 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] Milestones changed for dnssd WG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 10:06:49 -0000 Changed milestone "Formation of the WG", resolved as "Done". Changed milestone "Adopt requirements draft as WG document", resolved as "Done". Changed milestone "Submit requirements draft to the IESG as an Informational RFC", resolved as "Done". Changed milestone "Adopt wide-area service discovery solution draft as WG document ", resolved as "Done". Changed milestone "Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services", resolved as "Done". Added milestone "Confirm long-lived queries draft as WG document", due August 2015. Added milestone "Adopt threat model draft as WG document", due September 2015. Added milestone "Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational", due September 2015. Added milestone " Submit wide-area service discovery solution draft to the IESG as Standards Track RFC", due September 2015. Added milestone "Adopt hybrid-proxy implementation draft as WG document", due November 2015. URL: https://datatracker.ietf.org/wg/dnssd/charter/ From nobody Wed Jul 22 09:34:04 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA51B2A89 for ; Wed, 22 Jul 2015 09:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wmliZFK7gKbx for ; Wed, 22 Jul 2015 09:33:56 -0700 (PDT) Received: from purin.rz.uni-konstanz.de (purin.rz.uni-konstanz.de [134.34.240.45]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B801B2A84 for ; Wed, 22 Jul 2015 09:33:54 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de ([134.34.240.62]) by viribus.rz.uni-konstanz.de with ESMTP; 22 Jul 2015 16:33:52 +0000 Received: from [10.55.1.17] (unknown [31.30.2.52]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: daniel.kaiser) by nkongsamba.rz.uni-konstanz.de (Postfix) with ESMTPSA id 9739EA00A0; Wed, 22 Jul 2015 18:33:52 +0200 (CEST) From: Daniel Kaiser To: dnssd@ietf.org Message-ID: <55AFC6B8.4030409@uni-konstanz.de> Date: Wed, 22 Jul 2015 18:37:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080503000704010707020508" Archived-At: Cc: ietf@rozanak.com Subject: [dnssd] dnssd privacy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:33:58 -0000 This is a multi-part message in MIME format. --------------080503000704010707020508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all, i am a PhD student working in the field of privacy with respect to service discovery protocols. I attended today's dnssd meeting where you asked for contributions to draft-rafiee-dnssd-mdns-threatmodel. If you think the part on privacy problems is worth extending, I would be glad to contribute. Further I wanted to ask about possible solutions for the privacy problem, which I think is especially relevant for services that carry sensitive data in the TXT record (e.g. _presence). RFC 7558 Section 6.6 proposes to give users an opt-in for scope selection. What do you think about a possibility for users to choose whom service information is offered to, while keeping the way it is now as a default (we wrote a paper about that [1]). Services which use sensitive TXT records tend to be relevant for only a small group of users anyway. This would demand the existence of pre-shared knowledge, which could be transmitted over an out-of band channel (e.g. Facebook or XMPP, giving users the possibility to privately offer information about services to an existing list of friends). kind regards Daniel [1] http://kops.uni-konstanz.de/handle/123456789/29817 --------------080503000704010707020508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

i am a PhD student working in the field of privacy with respect to service discovery protocols.
I attended today's dnssd meeting where you asked for contributions to draft-rafiee-dnssd-mdns-threatmodel.
If you think the part on privacy problems is worth extending, I would be glad to contribute.

Further I wanted to ask about possible solutions for the privacy problem,
which I think is especially relevant for services that carry sensitive data in the TXT record (e.g. _presence).
RFC 7558 Section 6.6 proposes to give users an opt-in for scope selection.
What do you think about a possibility for users to choose whom service information is offered to, while keeping the way it is now as a default (we wrote a paper about that [1]).
Services which use sensitive TXT records tend to be relevant for only a small group of users anyway.
This would demand the existence of pre-shared knowledge, which could be transmitted over
an out-of band channel (e.g. Facebook or XMPP, giving users the possibility to privately offer information about services
to an existing list of friends).

kind regards
Daniel

[1]  http://kops.uni-konstanz.de/handle/123456789/29817
 --------------080503000704010707020508-- From nobody Wed Jul 22 09:56:22 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8491A8F39 for ; Wed, 22 Jul 2015 09:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 hYJc2De690rI for ; Wed, 22 Jul 2015 09:56:19 -0700 (PDT) Received: from smtpg4.aruba.it (smtpweb131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id EA42D1A8AFE for ; Wed, 22 Jul 2015 09:56:18 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUvq1q0042NEPrz01UvqWF; Wed, 22 Jul 2015 18:55:50 +0200 Date: Wed, 22 Jul 2015 18:55:51 +0200 (CEST) From: Meetecho Team To: dnssd@ietf.org Message-ID: <1437446480.7.1437584151759.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6_422120303.1437584151755" Archived-At: Subject: [dnssd] Meetecho recordings of DNSSD WG session X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:56:20 -0000 ------=_Part_6_422120303.1437584151755 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DNSSD WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#DNSSD In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_6_422120303.1437584151755--