Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
draft-cheshire-dnsext-nbp-10

[Ballot comment]
The rewritten security considerations include two points a) had the protocol been developed with security in mind then it would have been done differently b) when a new/modern version is designed the requirement is that it have security measures appropriate to the environment in which it will be used.  Based on the changes, I'm changing to no objection.

[Ballot comment]
The rewritten security considerations include two points a) had the protocol been developed with security in mind then it would have been done differently b) when a new/modern version is designed the requirements is that it have security measures appropriate to the environment in which it will be used.  Based on the changes, I'm changing to no objection.

[Ballot discuss]
I am picking up Pasi's DISCUSS on this document.

I think the document should be clearer whether these requirements
represent some kind of IETF consensus, or just opinions of the
authors.  I'm guessing it's the latter, but this guess is mostly based
on the I-D file name (which won't be visible once this becomes an RFC).

I agree with Chris that Section 6 should be more realistic about the
security goals: things like determining the authenticity of received
information, or authority to request some information, can't usually
be done with zero configuration.  Even with non-zero configuration, a
security solution that's realistically deployable in e.g. enterprise
environment probably has to be able to leverage existing
authentication and authorization infrastructure (things like Active
Directory, Kerberos, or internal PKIs come to mind). Besides, the
problem solved by DNSSEC (authenticating a hierarchical delegation
structure) is quite different from securing an AppleTalk NBP like
protocol (even if the messages re-use DNS formats).

[Ballot discuss]
[Holding a discuss for IANA]
Section 7 should be clearer about the actions IANA is expected
to take when this document is approved.  Please add an IANA
considerations section, even if it says, "This document has
no IANA actions.").

IANA Evaluation comments/questions:

QUESTION: We understand that the Service Name is a 32-character
ASCII String. Should UTF8 be allowed? If so, would that be 32
octets or 32 characters?

Upon approval of this document, the IANA will create the registry
"Name Binding Protocol Namespace" at
http://www.iana.org/assignments/TBD

Registration Procedures: FCFS
Initial contents of this registry will be:

Service Name Reference
------------ ---------

[Ballot comment]
I find the name of the document and of the page headers completely misleading. IMO the name should be 'Requirements for Replacing AppleTalk Name Binding Protocol (NBP)'.

[Ballot discuss]
I think the document should be clearer whether these requirements
represent some kind of IETF consensus, or just opinions of the
authors.  I'm guessing it's the latter, but this guess is mostly based
on the I-D file name (which won't be visible once this becomes an RFC).

I agree with Chris that Section 6 should be more realistic about the
security goals: things like determining the authenticity of received
information, or authority to request some information, can't usually
be done with zero configuration.  Even with non-zero configuration, a
security solution that's realistically deployable in e.g. enterprise
environment probably has to be able to leverage existing
authentication and authorization infrastructure (things like Active
Directory, Kerberos, or internal PKIs come to mind). Besides, the
problem solved by DNSSEC (authenticating a hierarchical delegation
structure) is quite different from securing an AppleTalk NBP like
protocol (even if the messages re-use DNS formats).

Section 7 should probably be clearer what actions IANA is expected
to take when this document is approved (I'm guessing it's "none", but
then the text should say "This document has no IANA actions.").
[Holding a discuss for IANA]

[Ballot discuss]
I think the document should be clearer whether these requirements
represent some kind of IETF consensus, or just opinions of the
authors.  I'm guessing it's the latter, but this guess is mostly based
on the I-D file name (which won't be visible once this becomes an RFC).

I agree with Chris that Section 6 should be more realistic about the
security goals: things like determining the authenticity of received
information, or authority to request some information, can't usually
be done with zero configuration.  Even with non-zero configuration, a
security solution that's realistically deployable in e.g. enterprise
environment probably has to be able to leverage existing
authentication and authorization infrastructure (things like Active
Directory, Kerberos, or internal PKIs come to mind). Besides, the
problem solved by DNSSEC (authenticating a hierarchical delegation
structure) is quite different from securing an AppleTalk NBP like
protocol (even if the messages re-use DNS formats).

Section 7 should probably be clearer what actions IANA is expected
to take when this document is approved (I'm guessing it's "none", but
then the text should say "This document has no IANA actions.").

[Ballot comment]
I found the security considerations weak, albeit tolerable for this sort
of informational document.

Some discussion of the usability/deployability/security tradeoffs
between a zeroconf home network and a fully managed DNSSEC
infrastructure would be informative.  Further, I suspect it's a critical
requirement to replace Appletalk NBP that "no security" be a protocol option since there's no way to get something with the same
ease-of-use/ease-of-deployment profile in a home network.

Right now there are two security options proposed: none or manually
configured DNS unicast w/ DNSSEC.  While I consider the "none" option
very important since that's exactly the security I want to deploy on
my home WLAN when it comes to this protocol (WPA2-AES is good
enough for my home WLAN), there are scenarios where I might want
some sort of middle ground without having to administer a
DNS infrastructure.  For example, "make sure I connect
to the same file service as last time", or "make sure I use ipp/tls
to the printer service and it's the same printer service I used last
time".  Has any sort of leap-of-faith SSH-style keying been
considered within this framework?  Indeed, in a large corporation with
outsourced IT, getting competent DNSSEC management is probably not
feasible so "grassroots" security might be more viable.

[Ballot comment]
I found the security considerations weak, albeit tolerable for this sort
of informational document.

Right now there are two security options proposed: none or manually
configured DNS unicast w/ DNSSEC.  While I consider the "none" option
very important since that's exactly the security I want to deploy on
my home WLAN when it comes to this protocol (WPA2-AES is plenty good
enough for my home WLAN), there are scenarios where I might want
some sort of middle ground without having to administer a
DNS infrastructure.  For example, "make sure I connect
to the same file service as last time", or "make sure I use ipp/tls
to the printer service and it's the same printer service I used last
time".  Has any sort of leap-of-faith SSH-style keying been
considered within this framework?  Indeed, in a large corporation with
outsourced IT, getting competent DNSSEC management is probably not
feasible so "grassroots" security might be more viable.

[Ballot comment]
Section 3.15 (Immediate and Ongoing Information Presentation) describes user interface requirements rather than the underlying protocol requirements.  I suggest revising this
section in terms of the protocol requirements.