Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

str4d <str4d@i2pmail.org> Fri, 22 May 2015 04:43 UTC

Return-Path: <str4d@i2pmail.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6A1A9100 for <dnsop@ietfa.amsl.com>; Thu, 21 May 2015 21:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.586
X-Spam-Level: ****
X-Spam-Status: No, score=4.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 OJU6QL8AAt0J for <dnsop@ietfa.amsl.com>; Thu, 21 May 2015 21:43:14 -0700 (PDT)
Received: from mail01.sigterm.no (unknown [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FB31A90FF for <dnsop@ietf.org>; Thu, 21 May 2015 21:43:13 -0700 (PDT)
Received: by mail01.sigterm.no (Postfix, from userid 1006) id 7D5C72E3447; Fri, 22 May 2015 06:43:11 +0200 (CEST)
Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by mail01.sigterm.no (Postfix) with ESMTP id D5CAA2E340F for <dnsop@ietf.org>; Fri, 22 May 2015 06:43:00 +0200 (CEST)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
To: dnsop@ietf.org
References: <555CC061.7040109@gmail.com> <5A8378EF-97B3-44AE-B6E7-4873D68B18F6@hopcount.ca> <20150521165548.386B9AE41E@smtp.postman.i2p>
In-Reply-To: <20150521165548.386B9AE41E@smtp.postman.i2p>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Message-Id: <20150521210825.1D6E0AE420@smtp.postman.i2p>
Date: Thu, 21 May 2015 21:08:25 +0000
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/mmZEQhEbOgBZdml-321mP_pEDp0>
Subject: Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 22 May 2015 04:43:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bob Harold wrote:
> On Wed, May 20, 2015 at 1:55 PM, Joe Abley <jabley@hopcount.ca>
> wrote:
> 
>> ... I would also support (as I have heard others say before, and
>> as I think I have also said) a separate document that provides
>> advice to anybody else planning to deploy code that uses a
>> DNS-like namespace that is not the DNS. Such people should either
>> make their names unambiguously different from those used in the
>> DNS, or should anchor them somewhere else in the namespace where
>> defensive registrations in the DNS are less contentious. For
>> example, if the Tor project had used "onion.eff.org" instead of 
>> "onion", we would not be having this conversation. Making such
>> guidance available would make it far easier to deal with the
>> future possibility that a decision with "onion" would set an
>> unfortunate precedent.
>> 
> ... The "onion.eff.org" idea only solves half of the problems - it
> would prevent others from using the domain for something else, but
> it fails to provide the required privacy - part of the requirement
> is that the onion names NOT be sent to DNS servers at all, for
> privacy.

The other reason this fails (partly linked to the privacy issue above)
is because it puts the entire .onion domain in control of a single
zone file. Even if the organization controlling that zone file is
trustworthy, it only takes a single compromise (and who hasn't heard
of DNS zones being hijacked?) for someone to add "legitimate" records
for e.g. facebookcorewwwi.onion.eff.org pointing to malicious servers
on the clearnet. This is not a privacy issue, it is a direct and
abject compromise of the security properties expected of a .onion addres
s.

For apps that already have a centralized model, the suggestion is not
as bad. But for .onion (and the .TLDs in the P2PNames draft),
centralized control is exactly what the technical protocols are
avoiding, and it is irresponsible to provide a "golden key" that could
be used to subvert them.

str4d

> 
> -- Bob Harold
> 
> 
> 
> _______________________________________________ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVXkk+AAoJEBO17ljAn7Pgm8MP/iIh8IOPTIKiUd2Ka59P8iEg
D+YJkMWD3IAuOER8cnGs2Nz7I5JGxxQdc5AUTUKmwnCHp9M7N2RQIuXWOczZ7izE
/XzY9ZojgVb/CvDqPG5qTR8kAo+Q3NHX3r5Dj+dJJUmVpP3i5toHpekXSHtwBUm4
pieRpL/3x9GQHTqg2GAwsqEFHMK7821Wy4QBslt7Q8zb7CqS+0yLHyWYs1cYNXQp
vKP92yR2UGiW+iwvQAAWlXnfFgzS4Rjrnkz8oMBuLa9zEa5r5puFAMoqSTmu8IcT
i345lUQ7ZsQ3OzfILGsvisGhJ4cyGVFvm0qvbGZNC3FPReAyge3EoQUDrgme+Fsc
hNRKwMjWL5NIHG8iPxs6Wu+u7QebYA/jBUQPNi1WgEpPeU5SRRStu45jOHtH/V8U
t6+8tzu4pyqPEHoemfuSdxE3FvFTSaknba3iYhEXZIDAzF6FNTMuUUJqLekH6zCy
+KA4K9f/NR/jOrUDkgV8f/x5HFApoZOnutOL4m/k7aNbK6gCIs/Lz/2NGD5MtZ6b
5GrQQixDrbarw7OpNeVv9v2bT4JP33vxf5ZexFUJg+jyyM0kzxaWMvmOANRAaDHf
vorzDKCmMRDx6f4OxwWXfVe1nM7+DTzd2WS6YCoPSOf6cJBRKcuYj5sNk+Lp+XvD
GX8ByEF3laN93RaLKDkA
=hfI/
-----END PGP SIGNATURE-----