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

Mark Nottingham <mnot@mnot.net> Tue, 01 September 2015 00:47 UTC

Return-Path: <mnot@mnot.net>
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 CBD671A8AA5; Mon, 31 Aug 2015 17:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 yh-uPv7fi1Zr; Mon, 31 Aug 2015 17:47:47 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA971A8735; Mon, 31 Aug 2015 17:47:47 -0700 (PDT)
Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 109CD22E200; Mon, 31 Aug 2015 20:47:42 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <003001d0e40e$5ce522e0$16af68a0$@huitema.net>
Date: Tue, 1 Sep 2015 10:47:39 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E6CC84B-791C-4016-9934-3F75083E4C70@mnot.net>
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> <CALaySJLD7WQG_2Zj2bU1_1TvTOVtVnw+YdirupFX5eAYu4CVOA@mail.gmail.com> <E178C22F-11F1-4FD7-89CC-5B2F8D1F3C44@mnot.net> <55E22119.9080106@bogus.com> <E8D38479-5B77-4D60-9D19-5F697A2DFC89@mnot.net> <003001d0e40e$5ce522e0$16af68a0$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/tzBqeqxbZ_iuo0AZQ-vFNZc6QYg>
Cc: secdir <secdir@ietf.org>, Alec Muffett <alecm@fb.com>, joel jaeggli <joelja@bogus.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, draft-ietf-dnsop-onion-tld.all@tools.ietf.org, Brad Hill <hillbrad@fb.com>, The IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>
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: Tue, 01 Sep 2015 00:47:50 -0000

On 1 Sep 2015, at 2:59 am, Christian Huitema <huitema@huitema.net> wrote:
> 
> 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.

Is that just a drop-in replacement for this?

"""
If client software attempts to resolve a .onion name, it can leak the identity
of the service that the user is attempting to access to DNS resolvers,
authoritative DNS servers, and observers on the intervening network. This risk
is mitigated when the recommendations in {{onion}} are followed, but are still
present when using systems that are not updated.
"""

Cheers,

--
Mark Nottingham   https://www.mnot.net/