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

From: [email-masked]
Date: Sat, 04 Jul 2015 14:25:11 -0700

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: Andrew Sullivan <[email-masked]>
Date: Sat, 4 Jul 2015 20:23:21 -0400

Hi,

> 	Filename        : draft-ietf-dnssd-mdns-dns-interop-01.txt

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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Jul 2015 18:25:11 -0700

> 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: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jul 2015 22:42:40 -0400

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'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).

> rather messy conversion issues and resulting visual

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.  

> 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

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.

> 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
> 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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 7 Jul 2015 18:58:25 -0700

> policy role) has instructed ICANN-IANA to do, I'd be interested to
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 <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.

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.

> 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!
> 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.
> 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.
> 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
> 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?
> U-labels are for display.  A-labels are for lookup.
Not using A-Labels can establish a locally resolvable
namespace and user friendly displays.
> except insofar as the normal UI context constrain the way that lookups
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.
> 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: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Jul 2015 22:43:30 -0400

> 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 be automatically assumed.

I'm sorry; I don't understand this paragraph.  What would you like to
be different?

> 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?

> Do not express an expectation DNS-SD domains are to always

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?

> 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

Surely mDNS just shouldn't respond from the DNS -- that is, an mDNS
responder ought not to respond to queries on port 53.

> 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.

> 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?  

> 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.  

> 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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Jul 2015 00:48:41 -0700

> 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.

> technologies.  So by definition they have to be.

Rather than omitting an important consideration, state the
need for global exclusions.

> 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

> 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.

> 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.

> 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.

> 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

That clearly states the problem we seem to be having.

> service, you have to be able to handle DNS operations.  Why is this

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.

> 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.

> 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

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: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Jul 2015 10:20:02 -0400

On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote:
> 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.

> in the profile should be excluded from resolving in a global

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.

> need for global exclusions.

But see above.  There is not in fact such a need; rather, stating such
a need would be false.

> 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.
 
> 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.

> 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.

> 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.

> 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

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.

> displayed having user friendly encoding.

Wait.  So your issue is that DNS-SD owner names are intended to be
seen by humans?  

> IDNA2008

Yes, which is why only the <Domain> 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 <Domain> 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
<Domain> portion or else DNS will just return RCODE 3 and you won't
find what you're looking for.

> DNS is able to use the SAME octets as used by mDNS.

Yes, which is entirely consistent with what I said.  

> There

What exactly is "local DNS"?

> 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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Jul 2015 19:37:50 -0700

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.

> completely different protocol.

Except when mDNS resources are automatically transferred to
DNS.  mDNS is even able to cache DNS resources.

>     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.

> 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?

> But see above.  There is not in fact such a need; rather, stating such

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.

> 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?

> 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

The situation is serious but not fatal if caution were to
prevail.

> DNS"?  I'm prepared to add that if you like.

It seems it would be more constructive as part of a
comprehensive strategy.

> 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

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.

> think that's a feature, but I'm willing to include the sentence noted

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.

> That has absolutely nothing to do with DNS-anythingelse

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.

> Wait.  So your issue is that DNS-SD owner names are intended to be

Clearly an issue whenever IDNA encoding is imposed on
exclusively local resources where user interfaces don't
support their conversion.

> below the <Domain> portion of a Service Instance Name.  That's because

Which is why there should be a strategy to restrict global
access to just resources that are administratively permitted.

> What exactly is "local DNS"?

This might employ a split horizon server excluding interface
and resolver access from specifically "profiled" zones.

> 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: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Jul 2015 19:31:40 -0400

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 <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 17 Jul 2015 18:27:03 +0200

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

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sat, 18 Jul 2015 15:20:58 +0200

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Jul 2015 11:32:56 +0200

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.

> don't see why it ought to be controversial; I also don't know how it's

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

> 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.

> 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.

>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.

> 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.)

> 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.

> Wait.  So your issue is that DNS-SD owner names are intended to be

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.

> 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.

> 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

>> 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

and

(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: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2015 16:53:32 +0200

On Mon, Jul 20, 2015 at 11:32:56AM +0200, Douglas Otis wrote:
> 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.  

> environments as a method to overcome WiFi limitations.

I don't know what this means.

> 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.

> 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.

> locally defined domain are automatically assumed global.

There is no such assumption.

> regarding absolute assertions of TLDs seen within a local

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.

> 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.

> how such zones are ascertained?

Because you have no idea whether a domain is "local", however that
works, or not.

> space referenced in RFC7368.

Well, it's hinted at by 7368.  It's not actually specified anywhere
yet.

> accessible domains

There is no such thing as this beast.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Jul 2015 19:57:13 +0200

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.

> 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.

> matter of policy, a restriction on what they'll accept, and it

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.

> too bad.  That's what you get for making up a random name and using it

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.

> 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.

> somewhere, and this profile is intended to restrict the number of

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.

> There is no such assumption.

The statement made regarding the use of A-labels below all
TLDs IS making this assumption in my view.

> my box, I see lots of .com and .org.  I presume that's not what you

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.

> look something up.  If we knew that, we wouldn't need any of this

It seems there is also little desire to implement IDNA2008
encoding for locally defined resources as well.

> obvious to people, though the experience with home, corp, and mail

A split horizon DNS scheme should override and prevent ill
considered redirection to "partner" sites.

> Because you have no idea whether a domain is "local", however that

The local DNS resolver knows and resolves resources properly
which provides a way of knowing.

> 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: Tim Chown <[email-masked]>
Date: Tue, 21 Jul 2015 17:16:26 +0100

Hi Doug,

> On 18 Jul 2015, at 14:20, Douglas Otis <[email-masked]> wrote:
> 
> ...
> 

> …

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 <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: Douglas Otis <[email-masked]>
Date: Wed, 22 Jul 2015 09:06:02 +0200

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