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

[Douglas Otis <[e-mail]>]

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

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