ietf
[Top] [All Lists]

Re: Last Call: <draft-cheshire-dnsext-dns-sd-07.txt> (DNS-Based Service Discovery) to Proposed Standard

2010-12-16 03:02:58
On Tue, 14 Dec 2010, Stuart Cheshire wrote:
On 17 Nov 2010, at 11:32 PM, Pekka Savola wrote:
The entire document is talking about how an app developer should use it. "It" in this context is the domain name system. DNS-SD is not a protocol in itself. It's a usage convention for DNS records. The entire document is telling server developers what DNS records we recommend they use to describe their service, and telling client developers what DNS records we recommend they query for to discover those advertised services. It describes what app developers should pick for Instance names and Service names. It describes what data app developers should put into TXT records. If we took out all the text directed at app developers there would be virtually nothing left. They are the audience for this document.

In a way, I understand that it could be argued that this is just a "naming convention" (also see the security considerations below).

Practically, however, it could be said to describe at least the solution framework. In practise, it describes the functionality that should be implemented in a DNS-SD software library the apps can link to, or even some kind of separate sofware package. While implementing everything described here would also be doable in each application (no doubt some will do so), that would be waste.

The point is underlined in e.g. how DNS-updates or related DNSSEC keying material would be configured, i.e. everything where there's more to it than just a naming convention.

17. Security Considerations

   DNSSEC [RFC 2535] should be used where the authenticity of
   information is important. Since DNS-SD is just a naming and usage
   convention for records in the existing DNS system, it has no specific
   additional security requirements over and above those that already
   apply to DNS queries and DNS updates.

.. this is a bit weak. There's more stuff to put in DNS updates. See the
referred sec-dir review from two years ago.  The text is unchanged.

The sec-dir review said "I find this inadequate" and "this document seems to need more work". Can you suggest some specific text? DNS-SD is a convention for how to name and use DNS records. Every security consideration that applies to a client using DNS queries and updates would apply to a client following the conventions in this document.

From my POV, the most important thing I'd like to see in Security
Considerations section is description of that app developer will be able do the DNS updates, hopefully in a secure fashion.

Some examples of what I wonder:

 - Is the expectation that you configure the DNS server so that
   certain IP's have complete access to do updates?

 - What does that imply?  Is it possible to limit the update
   capability to some subtree?  What kind of configuration would it
   need if it should be application-specific? (I.e., if one
   application gets out of hand, can it mess up all other apps or even
   the whole DNS domain?)

 - Or do you expect deployment of DNS security (e.g. TSIG, SIG0)? If
   so, how do you configure these in the app and the server within the
   constraints of zero-conf goals?  Do the same DNS subtree
   limitations and caveats apply?

To sum it up, I suspect the zeroconf nature of the goals of this work is likely to prevent the use of TSIG/SIG(0) in DNS-updates, or at least it requires major manual operations and/or it effectively authorizes one application to update every other application's data as well. But in some contexts it could be possible to implement it in a different way.

Editorial:
----------

 - IANA considerations does not explicitly mention 'DNS-SD profile'
   referred to in S 6 (though you can work out what you mean).

Can you suggest some specific text?

The minimal fix would be to change:

   This document specifies the following IANA allocation policy for
   unique application protocol names:

to:

   This document specifies the following IANA allocation policy for
   unique application protocol names (DNS-SD profiles):

... but it would still leave IANA considerations a big ambiguous. It would be much better if the required checklist on what to report and how IANA should record it in its registry was in a tabular format. While it's not in tabular format, the bullet list at http://www.dns-sd.org/ServiceTypes.html describes this rather well.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf