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

Alec Muffett <alecm@fb.com> Wed, 02 September 2015 11:51 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 0FBBB1ACEAD; Wed, 2 Sep 2015 04:51:46 -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_75=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 nP7J_pET8hOb; Wed, 2 Sep 2015 04:51:44 -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 5A5BA1A8AF5; Wed, 2 Sep 2015 04:51:42 -0700 (PDT)
Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t82BpYjc011822; Wed, 2 Sep 2015 04:51:34 -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=6j3C8iXf33Kk6iFt88TiMQK0oo8Tfcv/mAHoixosJ5k=; b=IBJgDNb2Zsuj1c18HLjfJlno7Iy1v9uL/OpXQD+R+e7DgfWZeoiZFllw+sRdvv4Upax6 7JyuI91Hy76OS/8SN4KhfQ5Agfp1tr8lf8XAjtk3gvfi9dEyeuXREC6QljKkyhHl5H1F 481X/SZTTYkNlg+YDFddfbyfEQSSzpQoAg4=
Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1wnrmvrsyn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 04:51:34 -0700
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB08.TheFacebook.com ([fe80::c9c7:30fd:ad3:b94%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 04:51:33 -0700
From: Alec Muffett <alecm@fb.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt
Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgAAAhtsA
Date: Wed, 2 Sep 2015 11:51:32 +0000
Message-ID: <B5605B1D-2788-4BEB-A72A-493B04BA8213@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>
In-Reply-To: <B7EB3E50-6F5C-4F40-80DA-3379D513514A@fb.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.54.13]
Content-Type: multipart/signed; boundary="Apple-Mail=_790B9BCC-A56D-4EB1-8BA5-69E7342AF6E9"; 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/Rf5VJSURy8STNfDZ4S6AoFB5mkY>
Cc: secdir <secdir@ietf.org>, joel jaeggli <joelja@bogus.com>, Mark Nottingham <mnot@mnot.net>, "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 11:51:46 -0000

Ah, apologies, I see that I have just been unclear:


> On Sep 2, 2015, at 12:36 PM, Alec Muffett <alecm@fb.com> wrote:
> 
> I think Mark’s revisions nail this with the “legacy client” paragraph.  :-)

…nails the “blackholing DNS” matter with the “legacy client” paragraph.  :-)


I am quite confident that Mark’s latest diff:

http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt <http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt>

…covers the “human factors” element quite well.



The primary risks to users of Onion names are:

* prefix collision phishing such as facebookXXX.onion versus facebookYYY.onion
** best mitigation: SSL, hence this draft
** documented

   Users must take special precautions to ensure that the .onion name
   they are communicating with is the intended one, as attackers may be
   able to find keys which produce service names that are visually or
   semantically similar to the desired service.  This risk is magnified
   because .onion names are typically not human-meaningful.  It can be
   mitigated by generating human meaningful .onion names (at
   considerable computing expense), or through users using bookmarks and
   other trusted stores when following links.


* tld proxy-phishing facebookXXX.onion (real) versus facebookXXX.onion.tld (proxy)
** best mitigation: again, SSL, hence this draft
** documented

   Also, users need to understand the difference between a .onion name
   used and accessed directly via Tor-capable software, versus .onion
   subdomains of other top-level domain names and providers (e.g., the
   difference between example.onion and example.onion.tld).


* leakage (risk to user)
** best mitigation: use current software. DNS NXDOMAIN will help reduce risk.
** documented

   A legacy client may inadvertently attempt to resolve a ".onion" name
   through the DNS.  This causes a disclosure that the client is using
   TOR to reach a specific service.  Malicious resolvers could be
   engineered to capture and record such leaks, which might have very
   adverse consequences for the well-being of the TOR user.  This issue
   is mitigated if the client's TOR software is updated to not leak such
   queries, or if the client's DNS software is updated to drop any
   request to the ".onion" TLD.


—
Alec Muffett
Security Infrastructure
Facebook Engineering
London