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

"Christian Huitema" <huitema@huitema.net> Tue, 01 September 2015 04:39 UTC

Return-Path: <huitema@huitema.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 BD2201B604E for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2015 21:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Mbcn6_ASF8eo for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2015 21:39:27 -0700 (PDT)
Received: from xsmtp06.mail2web.com (xsmtp26.mail2web.com [168.144.250.193]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E891B5DE8 for <secdir@ietf.org>; Mon, 31 Aug 2015 21:39:27 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ZWdLu-00052J-56 for secdir@ietf.org; Tue, 01 Sep 2015 00:39:26 -0400
Received: (qmail 7162 invoked from network); 1 Sep 2015 04:39:21 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <alecm@fb.com>; 1 Sep 2015 04:39:20 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Mark Nottingham' <mnot@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> <4E6CC84B-791C-4016-9934-3F75083E4C70@mnot.net>
In-Reply-To: <4E6CC84B-791C-4016-9934-3F75083E4C70@mnot.net>
Date: Mon, 31 Aug 2015 21:39:22 -0700
Message-ID: <009901d0e470$2e74c8e0$8b5e5aa0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQI50R8PuDN5FgYzzyJG3m5SgMEMYAJVzMtaAgL9VGEBO6r6yQGDmJGEAalbUnsCAexJawG5pZLqA2GpAUICMMzT8JzEwRSA
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/pPsLxdQzmNnMrpJ-XqE3ZD9vk4k>
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 04:39:28 -0000

On Monday, August 31, 2015 5:48 PM, Mark Nottingham wrote
> 
> 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.
> """

You challenged me to produce some text, so I did... But I should have taken
a closer look at your change. We are definitely expressing the same idea. My
text is perhaps a bit more explicit, but it lacks the pointer to the
specific section in which the recommendations are made. Your text maybe
lacks the motivating part that fixing DNS software is part of "defense in
depth."

-- Christian Huitema