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

Mark Nottingham <mnot@mnot.net> Tue, 01 September 2015 08:25 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 DEF4B1B8878; Tue, 1 Sep 2015 01:25:29 -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 YegHOo0drsll; Tue, 1 Sep 2015 01:25:27 -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 BEEC81B899C; Tue, 1 Sep 2015 01:25:27 -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 11D3522E2E7; Tue, 1 Sep 2015 04:25:22 -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: <009901d0e470$2e74c8e0$8b5e5aa0$@huitema.net>
Date: Tue, 01 Sep 2015 18:25:19 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C5092C0-36BA-47C2-A80E-02B09957E03F@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> <009901d0e470$2e74c8e0$8b5e5aa0$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/iELwUrp9-1cLwkdD34lITujJo1M>
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 08:25:30 -0000

Applied in <https://github.com/mnot/I-D/commit/61535215c7b2fcf864faf08ada7b6117bf9a88d9>.

Thanks,


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

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