Re: [dnssd] draft-ietf-dnssd-mdns-dns-interop and draft-otis-dnssd-scalable-dns-sd-threats

[Andrew Sullivan <[e-mail]>]

Hi Doug,

I continue to think that you and I are divided here by a common
language.  I do also think that split-brain DNS is, when also mixing
namespaces, dangerous (and yes, the "spinning knives" remark was
intended to lighten a discussion that can otherwise get heated).  But
it sounds like we need to sit down at some point and see whether I can
better understand how you want this draft to change.  It'll be very
difficult this week, though if you want to talk during bits & bytes
this evening I'll be around.  Alternatively, maybe we need to plan to
talk once everyone has made it back home.  We can try to co-ordinate
off-list?

Best regards,

A

On Tue, Nov 03, 2015 at 07:39:42AM +0900, Douglas Otis wrote:
> 
> Dear Andrew,
> 
> Your revised version would have been helpful.  My
> understanding of what you wish avoided in the threat review,
> humorously referred to as advice on juggling spinning
> knives, differs from WG agreements reached at the last meeting.
> 
> This covers exceptions made by domain owners who are not
> prohibited nor assured produce negative answers.  Such
> exceptions clearly demarcated with the use of DNS-SD
> conventions permit more liberal repertoires to convey
> locally defined network space under current protocol
> conventions which may be published globally.  Most of these
> conventions have or are now undergoing last call.
> 
> There was no mention of a parallel A-label namespace to be
> created, nor expectations of negative answers becoming the norm.
> 
> You assert DNS-SD conventions will result in a significant
> increase in DNS lookup traffic of no value. Further you
> assert that since adoption of RFC6763, increased use of IDNA
> makes the situation worse.  As such, your view is to rule
> out considerations regarding this namespace.
> 
> The <Domain> Portion of the Service Instance Name includes
> what the DNS-SD Scalable Threats document describes as--
> 
> <Instance>._<sn>._<Proto>.<SrvDOM>.<ParentDOM>.
> 
> <SrvDOM> is described in RFC6763 as <servicedomain> which
> encourages use of a more liberal repertoire. At the last
> meeting, it seemed agreement had been reached regarding
> exceptions for the <SrvDOM> portion of the namespace.
> 
> The modicum of advice was to use '_' in place of punctuation
> or spaces to reduce errors in administrative review or those
> caused by code expecting neither space or punctuation.  This
> advice can be removed if the WG considers it not warranted.
>  After all, since RFC6763 was written, applications have
> become far better at handling UTF-8. The domain owner will
> be impacted by any additional queries caused by erroneous
> handling of DNS-SD resources and can assess the value of
> allowing more liberal repertoires.
> 
> RFC6763 states in section
> 7.2.  Service Name Length Limits
> ,--
> Typically, DNS-SD service records are placed into subdomains
> of their own beneath a company's existing domain name.
> Since these subdomains are intended to be accessed through
> graphical user interfaces, not typed on a command line, they
> are frequently long and descriptive.  Including the length
> byte, the user-visible service domain may be up
> to 64 bytes.
> '--
> 
> RFC6763 further states in section
> 4.1.3.  Domain Names
> ,--
> Because Service Instance Names are not host names, they are
> not constrained by the usual rules for host names [RFC1033]
> [RFC1034] [RFC1035], and rich-text service subdomains are
> allowed and encouraged, for example:
> 
>      Building 2, 1st Floor  .  example  .  com  .
> ...
> 
> In cases where the DNS server returns a negative response
> for the name in question, client software MAY choose to
> retry the query using the "Punycode" algorithm [RFC3492] to
> convert the UTF-8 name to an IDNA "A-label" [RFC5890],
> beginning with the top-level label, then issuing the query
> repeatedly, with successively more labels translated to IDNA
> A-labels each time, and giving up if it has converted all
> labels to IDNA A-labels and the query still fails.
> '--
> 
> The interop draft overlooks existing conventions surrounding
> DNS-SD and offers far less guidance than that given in the
> threat review.  If your assertions are correct about the
> risk, much more needs to be said and not less.
> 
> Regards,
> Douglas Otis
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd

-- 
Andrew Sullivan
[e-mail]