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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf