[dnssd] draft-ietf-dnssd-mdns-dns-interop and draft-otis-dnssd-scalable-dns-sd-threats
Douglas Otis <doug.mtview@gmail.com> Mon, 02 November 2015 22:36 UTC
Return-Path: <doug.mtview@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59E1A8A0F for <dnssd@ietfa.amsl.com>; Mon, 2 Nov 2015 14:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7mJjFexjRSw for <dnssd@ietfa.amsl.com>; Mon, 2 Nov 2015 14:36:58 -0800 (PST)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247FD1A8A0E for <dnssd@ietf.org>; Mon, 2 Nov 2015 14:36:58 -0800 (PST)
Received: by padec8 with SMTP id ec8so51952323pad.1 for <dnssd@ietf.org>; Mon, 02 Nov 2015 14:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=f+xPl6XRrdGH+kFhvAa7Z6Lvxj44D27QdF+vT95kkLo=; b=QYfNd0l/TtSj2HDjU6MRl//aBzAHqSAHv0hEzkS3DNBDz7aaDSxcqT6yvgBrhTFAPS f65+Jc5RfMLhyowUUX2Tf1lIV/5/RzR0lD0aFeGX2xJ6gYRuC+w3NVAMYZXNtkXs+vir kBHVuQ20srTJgQt2MI7C8UuXlIqrTb7RclTYOichAC3LTVLmrEumkHnMa359VBql6ug0 nI4FARCA/CaBv+PQDtPt6m/slBq77W3v4SHvjnTLKjesUiVtNEM/cfgSnM3hiVF76lqX 8y3zWRckUq4BxsKGHEbJLSSWBl2GOLUDxBIm0lec06hCm49k6Z8NPwoeHAe8n93wLiZM Cg6A==
X-Received: by 10.68.165.194 with SMTP id za2mr29688024pbb.72.1446503817797; Mon, 02 Nov 2015 14:36:57 -0800 (PST)
Received: from US-DOUGO-MAC.local ([101.110.53.38]) by smtp.googlemail.com with ESMTPSA id pn8sm25919028pbb.16.2015.11.02.14.36.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:36:57 -0800 (PST)
To: dnssd@ietf.org
References: <20151102040738.1146.98238.idtracker@ietfa.amsl.com> <20151102054146.GC876@mx2.yitter.info>
From: Douglas Otis <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5637E62E.2050105@gmail.com>
Date: Tue, 03 Nov 2015 07:39:42 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151102054146.GC876@mx2.yitter.info>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/kM3WNCepJmaiayygmbOiIuVuI3g>
Subject: [dnssd] draft-ietf-dnssd-mdns-dns-interop and draft-otis-dnssd-scalable-dns-sd-threats
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 22:36:59 -0000
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] I-D Action: draft-ietf-dnssd-mdns-dns-int… internet-drafts
- Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns… Andrew Sullivan
- [dnssd] draft-ietf-dnssd-mdns-dns-interop and dra… Douglas Otis
- Re: [dnssd] draft-ietf-dnssd-mdns-dns-interop and… Andrew Sullivan