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

[Douglas Otis <[e-mail]>]

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

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