Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt

Alec Muffett <alecm@fb.com> Wed, 02 September 2015 15:09 UTC

Return-Path: <prvs=66879520af=alecm@fb.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49E1B49AA; Wed, 2 Sep 2015 08:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 LrubrfpIHR4E; Wed, 2 Sep 2015 08:09:31 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B021B498C; Wed, 2 Sep 2015 08:09:25 -0700 (PDT)
Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t82F6QlW005337; Wed, 2 Sep 2015 08:09:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=4numPYA7LG4AUgteS4vaImcPmeBPI2btpvbXXFU197k=; b=Nj4TgmwTFdF+90q41kjcBhZRYKYq/euF7k9xLrVHlpZirNziNdO9c9HCfx2hcMZ8g2xk d2JT4jkNou5nFkrvoCILbWDN2Wh8T9yy3qyJU7AAcIjgeJ0nMtcmFNvBlquRlNHzySYn xK+3Bzr6krcb4x1raDvbZ6zzD9u+EJtqjS4=
Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1wp1f1g8d1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 08:09:14 -0700
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 08:09:13 -0700
From: Alec Muffett <alecm@fb.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt
Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgAAAhtsAAAQNawAAAtmQAA==
Date: Wed, 02 Sep 2015 15:09:11 +0000
Message-ID: <88A83735-7C8C-49C6-BDE9-CB0CC6059AB6@fb.com>
References: <007601d0c2c3$7615b610$62412230$@huitema.net> <CAHbuEH7RSdDmJK3i0e0W+kW0TSsbCNqQx7S+ZKp1Zx+7-uRjhw@mail.gmail.com> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <CAHbuEH66yK9JqnnK4UnoC1wtkL1d6S-JeL5twx6izM9o-R_BNg@mail.gmail.com> <E865FFAE-26DE-4B03-A294-5CB64C660CB7@fb.com> <CAHbuEH7pNs8qvkdEyqQ2-WERfPVHkgYxYH7FaFekerdNm8srGg@mail.gmail.com> <B7EB3E50-6F5C-4F40-80DA-3379D513514A@fb.com> <B5605B1D-2788-4BEB-A72A-493B04BA8213@fb.com> <D20C73C3.CD207%aretana@cisco.com>
In-Reply-To: <D20C73C3.CD207%aretana@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.52.123]
Content-Type: multipart/signed; boundary="Apple-Mail=_9FEAFDDD-3C98-41F8-9527-C8A32F229211"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/6LloGvj4UdFd3_TVP3lVrmMAllI>
Cc: secdir <secdir@ietf.org>, Mark Nottingham <mnot@mnot.net>, joel jaeggli <joelja@bogus.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" <draft-ietf-dnsop-onion-tld.all@tools.ietf.org>, The IESG <iesg@ietf.org>, Brad Hill <hillbrad@fb.com>
Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 15:09:34 -0000

Hi Alvaro!

> On Sep 2, 2015, at 2:47 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
> There is more there, but as an average Internet user (not a Tor user) I still don’t know what to look out for if presented with a .onion name (or something that looks like it).

That’s a really good point - is this document fit for the purposes of people who click on a link, expect it to work, and are surprised when it does not?

An example of this - where I was the author, and so I took steps to explain what would not happen - is on this page:

https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237 <https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237>

For people who don’t want to load that page, the relevant part is:

>> …To make their experience more consistent with our goals of accessibility and security, we have begun an experiment which makes Facebook available directly over Tor network at the following URL:
>> https://facebookcorewwwi.onion/ <https://facebookcorewwwi.onion/>
>> [ NOTE: link will only work in Tor-enabled browsers ]

…and there’s the thing: someone who is not using Tor will click on a link and nothing will happen, exactly as (for instance) I visit a coffee shop or my workplace and click on the bookmarked “http://router.local/ <http://router.local/>“ link which (when I am at home) would give me access to my DSL router’s control panel.

>  I suspect that most average users will just click on something w/out realizing (ever!) it is a .onion name, and not a “plain old link” to some other page.

Quite.  I believe that that is, in fact, rather the design goal.  Interoperability.

The onion network space consists of software, exactly like any other software (LAMP stacks, Wordpress, Facebook, etc) which is just accessed via a different address space, the latter being similarly to some VPN software.

Equally, my aforementioned router.local link *will* work when my VPN into my home network is working properly.

Similarly (again) - in my browser bar there are any number of links - or, for that matter, SSH connections - on the Facebook-internal corporate network which are not accessible from (say) my local Starbucks, again unless I have my corporate VPN software enabled - at which point everything magically suddenly "just works".

(aside) This is why I have always felt that using a scheme-change “onion://“ would not have been a good design choice for Tor Onion Names; my work life would be significantly more complex if I had to swap schemes when accessing a site over a VPN, a-la htvpntp://non-dns-name.internal/foo.txt

Returning to your point:

> However, the more I read this thread the more I am convinced not much can be said/done.  Just like the facebookXXX.onion versus facebookYYY.onion case, average users don’t pay enough attention to distinguish between facebook.com and faceboook.com, much less would they know that .onion (or any other name for that matter) is special.  As you already wrote in the latest version, we can just hope that the appropriate sw is updated to prevent the average user from doing something they don’t even understand that may result in some leakage of information.

Yes indeed, and I believe that the Ballot-144-enabled adoption of EV Certificates, with their big friendly green labels, will do a lot to reduce unwanted intermediary risk in Onion space.

Also, in passing, I do wish to point out, those “fooXXX.onion.tld” proxies which I have elsewhere presented as an unwanted risk, also do have a wanted and important role to play in making the world more open and connected; the (independent, non-Tor) Tor2web project was co-founded by the late Aaron Swartz (of whom some of you may have heard / seen documentaries?) in order to allow sites to publish via Tor to maintain anonymity, and Tor2web serves as yet one more bridge for the larger non-Tor world to access Tor/Onion resources.

More details on Tor2web are at https://en.wikipedia.org/wiki/Tor2web <https://en.wikipedia.org/wiki/Tor2web> - but to recap: there is a separate, parallel space of information out there, one that has been available for about a decade, and in order to bring greater trust to it and ensure that it is on a sound footing requires it to be slotted into the bigger picture of the internet and web.

Hence this draft.  It is what we are trying to do. :-)

   - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London