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

Mark Nottingham <mnot@mnot.net> Tue, 01 September 2015 23:55 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 170C51B5063; Tue, 1 Sep 2015 16:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, 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 DW68M-mCCa3E; Tue, 1 Sep 2015 16:55:42 -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 791EB1B5054; Tue, 1 Sep 2015 16:55:42 -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 ABA4322E273; Tue, 1 Sep 2015 19:55:32 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAHbuEH67bFrBA_-XE+zzHG1tw0op4XOFTf1RrDkAdRtt_-s=hg@mail.gmail.com>
Date: Wed, 2 Sep 2015 09:55:29 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <65D73339-F470-4D78-89CD-907E76B229B0@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> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> <CAHbuEH67bFrBA_-XE+zzHG1tw0op4XOFTf1RrDkAdRtt_-s=hg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ehB1RJGSsJ9zosHujZgS6MqvcoQ>
Cc: secdir <secdir@ietf.org>, Alec Muffett <alecm@fb.com>, joel jaeggli <joelja@bogus.com>, draft-ietf-dnsop-onion-tld.all@tools.ietf.org, The IESG <iesg@ietf.org>, Brad Hill <hillbrad@fb.com>, 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 23:55:45 -0000

See:
  https://github.com/mnot/I-D/commit/f9975381389d556709cfe77a520eae73ace0659c
  https://github.com/mnot/I-D/commit/cb43f69aa37f94baeb78aa3eca368dd712a06154
Do they suffice?

The references were flipped to normative here:
  https://github.com/mnot/I-D/commit/8486c73357b0421c013a6e99e90374c54190ce36

With all changes to date incorporated:
  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt
  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.html

Cheers,

> On 2 Sep 2015, at 12:07 am, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema <huitema@huitema.net> wrote:
>> On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote:
>>> 
>>> I still have the outstanding question on security properties that may be buried
>>> in this thread.
>> 
>> The question was, how could malicious DNS agents trick TOR clients into disclosing their presence. The recent exchange with Mark was about such agents passively listening for clients' mistakes. Is there a way to actively trigger such mistakes?
>> 
>> Such attacks would require actively sending information to clients, such as "if you have a request for example.onion, send it to me." The way to do that in the DNS is through NS records. Malicious agents could send an NS record for ".onion" as additional record in a response, asking resolvers to send them such traffic. This might trick legacy clients. Maybe.
>> 
>> -- Christian Huitema
>> 
>> 
>> 
> 
> My outstanding question is in my message from Aug 30th on Section 2
> text that I think needs further clarification since the first bullet
> makes a broad statement without naming the security properties people
> are supposed to recognize.  Here is the snippet from that message
> (similar to a point made by Alvaro as well):
> 
>> That would seem doable, if something sufficiently brief can be constructed,
>> because much of the actual mechanism which should lead to the desired
>> behaviour is described in Section 2 of the draft, the elements of which are
>> heavily modeled upon the examples provided in RFC6761.
>> 
> 
> It's fine to have them in section 2.  When I read through them again,
> what are the special security properties that users and applications
> should recognize that are mentioned in the first bullet?  Are these
> properties provided through the subsequent bullets handling
> requirements?  I'm guessing that's the case, but since they are not
> sub-bullets, I'm not sure.
> 
> It would be good to clarify this text to list the properties and to
> see how the first bullet relates to the subsequent bullets.
> -- 
> 
> Best regards,
> Kathleen

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