Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt

Douglas Otis <doug.mtview@gmail.com> Wed, 08 July 2015 07:48 UTC

Return-Path: <doug.mtview@gmail.com>
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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietf.org>; Wed, 8 Jul 2015 00:48:45 -0700 (PDT)
Received: by obbgp5 with SMTP id gp5so33003542obb.0 for <dnssd@ietf.org>; 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 <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <559CD5D9.4030000@gmail.com>
Date: Wed, 08 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: <http://mailarchive.ietf.org/arch/msg/dnssd/yY0qOxRhCBC9MXJCuM5rBws9Hxs>
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." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=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 <Domain> 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