Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Mark Andrews <marka@isc.org> Sun, 03 April 2016 04:47 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBFB12D16B for <dnsop@ietfa.amsl.com>; Sat, 2 Apr 2016 21:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 iX5Url-Po-go for <dnsop@ietfa.amsl.com>; Sat, 2 Apr 2016 21:47:31 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A72F12D101 for <dnsop@ietf.org>; Sat, 2 Apr 2016 21:47:30 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 54FA41FCAB2; Sun, 3 Apr 2016 04:47:27 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 195D416005B; Sun, 3 Apr 2016 04:47:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 037F516007D; Sun, 3 Apr 2016 04:47:26 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id N53L8kIjP9Ki; Sun, 3 Apr 2016 04:47:25 +0000 (UTC)
Received: from rock.dv.isc.org (host113.190-229-41.telecom.net.ar [190.229.41.113]) by zmx1.isc.org (Postfix) with ESMTPSA id 9259816005B; Sun, 3 Apr 2016 04:47:25 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CBDDA45D1ED9; Sun, 3 Apr 2016 14:47:20 +1000 (EST)
To: Adrien de Croy <adrien@qbik.com>
From: Mark Andrews <marka@isc.org>
References: <em8bf94e58-4db5-4277-86ce-c0c5c0dc893f@bodybag>
In-reply-to: Your message of "Sun, 03 Apr 2016 02:51:40 +0000." <em8bf94e58-4db5-4277-86ce-c0c5c0dc893f@bodybag>
Date: Sun, 03 Apr 2016 14:47:20 +1000
Message-Id: <20160403044720.CBDDA45D1ED9@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Xm0bSYSws66ZcrTs6rlqGqBtsTU>
Cc: Robert Edmonds <edmonds@mycre.ws>, "dnsop@ietf.org" <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Apr 2016 04:47:33 -0000

In message <em8bf94e58-4db5-4277-86ce-c0c5c0dc893f@bodybag>, "Adrien de Croy" writes:
>
> that's correct.  It looks in that document like a quote from the IAB,
> but if you're saying it's not, I then would have to challenge the
> logical conclusion asserted in that second paragraph.
>
> I don't see why it necessarily follows that having a single tree with a
> single root creates a requirement for support for multiple resolution
> protocols.

Because the only other way to be able to distingish between a onion
address and a DNS name would be to have onion use labels with a
wire representaion that are longer that 63 octets or with overall
lengths greater that 255 wire octets or you have to prefix all names
with DNS and ONION to identify the resolution namespace.  Almost
any string of characters will form a valid DNS name.

This was my signature back in 1995.  Note you had to NAME the NAMESPACES.

	Mark Andrews, CSIRO Div Maths & Stats
	Locked Bag 17, North Ryde, NSW 2113, Australia.
	PHONE:  +61 2 325 3148                       INTERNET: marka@syd.dms.csiro.au
	UUCP: ....!uunet!syd.dms.csiro.au!marka

None of us grey beards want to go back to those days.

We could have added "*.onion 604800 IN NULL" to the root zone and
fixed all the resolvers to stop searching on NOERROR but that does
not stop the fact that you want to use TOR alone with who you want
to talk to leaking unintentionally.

> The thousands of authors of other protocols and systems don't seem to
> have had too much trouble so far just using DNS where required, and
> putting resolution into their own protocols outside the tree.  Why break
> the whole tree for some nebulous result which surely in all cases can be
> worked around with a smaller consequence than having to deploy new DNS
> to the entire world.
>
> Even a DSL/NAT box does DNS forwarding, do we expect all those cheap
> router box vendors to patch out the firmware for this any time soon?

No.  The expectation is that future boxes that they ship will
implement the protocol and not pass on the leaked name.  The
expectation is that any update issued will also address this.

The RFC allows DNS only resolvers, proxies and recursive servers
to all generate NXDOMAIN responses in the event of a leak.  This
will result in SERVFAIL in some cases as the validation of the
response will fail but it will still prevent the leak spreading.

> Adrien

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org