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

Mark Nottingham <mnot@mnot.net> Wed, 02 September 2015 01:44 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 5F5851B35BC; Tue, 1 Sep 2015 18:44:54 -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 cfpSvp5ge4CZ; Tue, 1 Sep 2015 18:44:52 -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 214091B340E; Tue, 1 Sep 2015 18:44:52 -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 2D40322E271; Tue, 1 Sep 2015 21:44:44 -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: <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net>
Date: Wed, 2 Sep 2015 11:44:42 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF14AC5A-A7C8-4B25-B621-D90E8FFD0B62@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> <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/IFIS9sfZqz2bZ9sPMoLb9K_PNpg>
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: Wed, 02 Sep 2015 01:44:54 -0000

Diff URL for the curious:
  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

Cheers,


> On 2 Sep 2015, at 9:55 am, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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/
> 

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