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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 02 September 2015 15:16 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 B34A61B4A92; Wed, 2 Sep 2015 08:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_75=0.6, 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 k6zokEKiKxgx; Wed, 2 Sep 2015 08:16:08 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 480E41B4A93; Wed, 2 Sep 2015 08:16:08 -0700 (PDT)
Received: by obcts10 with SMTP id ts10so10678920obc.1; Wed, 02 Sep 2015 08:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4/+ez9sfhxV/XjNMmhGisSyD8S9x/aWgzzNtvH7Qnt8=; b=zAY3saksIZ9Q3miaNdoHrtX+kpO45jkK3zhwU5ztQ8RTfPg94Vv7c5ReXwn1Z0MbND X6zyDjImsWMoI5XFIZeDYexmbwukhP5bjDfGGb5O64FVvuGTH76JokeuY9U5ICInQg51 BSTQ/4orgrwy3m4dvb2B0KB9S7vyLx+LMesHxMJi2GFrWL+/zK6mMY8m8a7zxCepE4vu h4SkQqXwEDpNZCEI7Vsq+M2fQVGSVcF3t9T9yvbDw7vTS2BpgZefSA7JfAZzgOSz9PVc UagmVL2Ve5XYLcLtIfW9DzVm6kC9+xHMSvBaa7Z2B0nqMZ297tQZp6pZBMtZBPUr+iNV xiAQ==
MIME-Version: 1.0
X-Received: by 10.182.58.105 with SMTP id p9mr20125609obq.11.1441206967690; Wed, 02 Sep 2015 08:16:07 -0700 (PDT)
Received: by 10.202.48.13 with HTTP; Wed, 2 Sep 2015 08:16:07 -0700 (PDT)
In-Reply-To: <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> <B5605B1D-2788-4BEB-A72A-493B04BA8213@fb.com>
Date: Wed, 2 Sep 2015 11:16:07 -0400
Message-ID: <CAHbuEH46R1U8Uv3Sz5XWk9KCR5rtvnG0JNKTVezacqDaOn6XJw@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Alec Muffett <alecm@fb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gokdYS2rEc9Cw3b4i916mEtjndE>
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 15:16:09 -0000

Thanks to you and Mark for addressing the outstanding questions from
the SecDir review and the one on "security properties".  What threw me
off is that what is described as security properties, I would call
security controls.  I'm not asking for a fix, but properties would be
more like confidentiality, integrity, etc., which the names themselves
do not provide.  The controls and usage provide additional protection.

Thanks,
Kathleen

On Wed, Sep 2, 2015 at 7:51 AM, Alec Muffett <alecm@fb.com> wrote:
>
> 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
>
> …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
>



-- 

Best regards,
Kathleen