Last Call Review of draft-ietf-dnssd-hybrid-07
review-ietf-dnssd-hybrid-07-secdir-lc-harkins-2017-10-19-00

Request Review of draft-ietf-dnssd-hybrid
Requested rev. no specific revision
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-10-12
Requested 2017-09-28
Other Reviews Opsdir Last Call review of -07 by Joel Jaeggli
Genart Last Call review of -07 by Joel Halpern
Review State Completed
Reviewer Dan Harkins
Review review-ietf-dnssd-hybrid-07-secdir-lc-harkins-2017-10-19
Posted at https://mailarchive.ietf.org/arch/msg/secdir/LUereu5JMsOJrfbIT0TFMBdmRlw
Reviewed rev. 07
Review result Has Nits
Draft last updated 2017-10-19
Review closed: 2017-10-19

Review
review-ietf-dnssd-hybrid-07-secdir-lc-harkins-2017-10-19

   Greetings,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   This draft describes a new type of proxy that uses multicast DNS
to discover multicast DNS records on local links and then makes
corresponding DNS records visible in the unicast DNS namespace.

   This is a very well written draft and is easy to read and understand.
I believe it is "Ready with nit". My nit is this:

   I understand that there is a general problem with restricting certain
DNS records but this draft seems to exacerbate that problem. The draft's
privacy considerations do discuss the case where a "Multicast Service
Discovery Proxy" makes records for transient devices from the local link
available to, theoretically, the global public DNS database and thereby
advertises the presence or absence of a laptop (and more importantly it's
owner from a house). This is a serious issue and I think the draft should
address it instead of punting the problem to "firewalls, split-view DNS,
and Virtual Private Networks". Due to my general DNS ignorance I am unable
to suggest a workable solution but there should be a way to instruct the
proxy to suppress certain records (perhaps encode something in the QNAME,
I don't know). I just think this draft creates a serious problem out of a
protocol limitation and it should provide some way to address it.

   regards,

   Dan.