Subject: [dns-dir] multicastdns (Re: "Bonjour" protocol doc suite)

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Dec 2010 07:41:36 -0500

On Thu, Nov 18, 2010 at 12:03:55PM +0000, Ralph Droms wrote:
> All three docs are in IETF last call and will are on the agenda of Dec 2 IESG telechat.  I'd like to get DNS Directorate reviews of the current rev of the docs prior to the telechat.  Has anyone begun any of the reviews?  Volunteers?
> 

I didn't see any other reviews, so I reviewed _very quickly_
draft-cheshire-dnsext-multicastdns-12.  

As I guess I've said before, I think this needs to be published, even
if it isn't perfect.  That said, I think it is in much better shape
than many documents.  I think it has the right mix of explanatory text
and specification.  I think the protocol is completely specified here.
(I spent some time working through some issues over the past year with
Bonjour using previous versions of this draft, and I was never able to
find things that weren't covered in it.  Would that I could say the
same thing for the DNS specifications!)

There remains in this document the awkward fact that it is directing
IANA to reserve part of the namespace.  The argument in Appendix G is
a little bizarre, given that the document officially says that it is
_not_ DNS but rather a DNS-like protocol on port 5353.  That said, the
same argument cites RFC 2860, and I think the argument is on stronger
ground there.

The rule in Appendix F that you're not allowed to put ACE-compatible
encodings in mDNS is obviously wrong on its face, because ASCII is
just a subset of UTF-8 and therefore any ACE-compatible encoded label
(what the IDNA2008 documents call an A-label) is automatically a valid
mDNS label, though one that will be hard to use.

The "just use UTF-8" approach in this document for
internationalization is probably not quite as effective as the authors
think it should be, but I think it is probably good enough for the
purposes.  I think the document does address in passing most of the
effective issues with this strategy (and says everything that can be
said without the document turning into a discussion of languages,
strings, scripts, and user interface design).  Since mDNS is intended
really for LAN use anyway, the bizarre situations that can arise with
such considerations on the global Internet are unlikely to arise in
this context.

I think the document is forthright that there is a potential security
nightmare in cases where mDNS is in use and there is intermittent
service from the global DNS.  The basic story it has for that is that
it amounts to a user interface problem.  This is a deeply unsatisfying
response, even though it appears to be true in practice.  There just
is no way to have a locally-scoped and globally-scoped namespace
available simultaneously to users, and to make it perfectly impossible
for an attacker to fake out users.  Given that we can't even achieve
such security in the globally-scoped namespace anyway, I am not sure
that such a goal is reasonable.

This protocol (or variations of it) are widely deployed.  I take
seriously Doug Barton's point that the IETF isn't here to stamp
"standard" on vendors' specifications, and it isn't clear that
different interoperating implementations can be generated from this
specification (since we have in the field different implementations
that seem to differ in their behaviour).  But the way we used to
address that was to publish the document as PS so that everyone had
something stable to implement against.  I have no idea whether Avahi
and the various Bonjours are all implemented agains the same draft,
and so we have an interoperability problem anyway.  So I think this
document should be published, and on the standards track.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Dec 2010 08:17:55 -0500

Hi,

Just as with the multicast DNS draft, I reviewed
draft-cheshire-dnsext-dns-sd-07 very quickly.  Sorry these are coming
so late.

I should note that as part of my day job, I've actually been working
with the dns-sd stuff for over a year.  As far as I can tell, it
works.  There are some actual interoperability problems between
Apple's Bonjour and Avahi; this is to me an argument that we need an
RFC out soon so that people have something stable against which to
implement.

The name of this approach is a little unfortunate, because it makes it
seem that it is intending to allow users to "discover their DNS".
That's not, of course, what it is doing: it presents a mechanism via
the DNS for users to discover other services.  

The discussion about structured service names in section 4.1 is rather
combative in tone, although having followed the history of this I
can't say that's surprising.  The plan to "fall back" to "Punycode" is
a bit of a disaster, in that the description talks about "converting
labels to Punycode".  It's worth quoting the entire passage:

   The <Domain> portion of the Service Instance Name specifies the DNS
   subdomain within which the service names are registered. It may be
   "local.", meaning "link-local Multicast DNS" [mDNS], or it may be
   a conventional unicast DNS domain name, such as "ietf.org.",
   "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are
   not host names, they are not constrained by the usual rules for host
   names [RFC 1033][RFC 1034][RFC 1035], and rich-text service
   subdomains are allowed and encouraged, for example:

     Building 2, 1st Floor  .  example  .  com  .
     Building 2, 2nd Floor  .  example  .  com  .
     Building 2, 3rd Floor  .  example  .  com  .
     Building 2, 4th Floor  .  example  .  com  .

   In addition, because Service Instance Names are not constrained by
   the limitations of host names, this document recommends that they
   be stored in the DNS, and communicated over the wire, encoded as
   straightforward canonical precomposed UTF-8, Unicode Normalization
   Form C [UAX15]. In cases where the DNS server returns a negative
   response for the name in question, client software MAY choose to
   retry the query using "Punycode" [RFC 3492] encoding, beginning with
   using Punycode encoding for the top level label, and then issuing
   the query repeatedly, with successively more labels converted to
   Punycode each time, and giving up if it has converted all labels
   to Punycode and the query still fails.

Now, the "fallback to Punycode" approach will work fine for the
portion of the identifier that is just the local part.  But claiming
that you can start at the top level and "convert the label to
Punycode" is an underspecification, since under IDNA2008 you're
supposed to check putative A-labels to see whether they are such
(though there cannot, of course, be a general-purpose rule that you're
not allowed to look up a putative A-label without checking it, since
your lookup might be IDNA-unaware).  The recommendation to use UTF-8
labels for the whole name is not consistent with IDNA2008
recommendations, although it will probably interoperate.  I would like
to suggest a single sentence advising users of this specification to
be aware of the constraints on domain names entailed by IDNA2008.  I
do _not_ think this should block publication of the document, but I
expect that there will be evidence that emerges soon about how this
works in practice (because of increasing IDNA deployment), and perhaps
as the document advances on the standards track this part can be
cleaned up in light of experience.

It is the rejection of the LDH rule that reveals the basic bias in the
document towards the LAN.  Nevertheless, mature DNS implementations
ought no longer to require the LDH rule for all labels (if ever they
did).  

While it would have been nice if they'd used an RRTYPE other than TXT
for part of this, the fact is that they used it, and it's widely
deployed.  It's too late to undo this.

If it were my protocol, I'd have done a more complete job on subtyping
(this has caused me some pain over the past year).  But within the
limits prescribed here, the subtyping seems to work, and the document
is quite clear that it isn't pretending to offer more.  Again, also,
the protocol is widely deployed, so attempting to change this is
unlikely to yield the results we want.

I think the document should be published, even though I'm a little
uncomfortable with the implications of the discussion in 4.1.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.