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

Mark Nottingham <mnot@mnot.net> Tue, 01 September 2015 08:36 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 768451B8A7E; Tue, 1 Sep 2015 01:36:07 -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 qKWk3DxKTDOp; Tue, 1 Sep 2015 01:36:03 -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 3C3811B8748; Tue, 1 Sep 2015 01:36:03 -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 BBF9722E2EF; Tue, 1 Sep 2015 04:35:58 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <55E414D7.3070600@cs.tcd.ie>
Date: Tue, 1 Sep 2015 18:35:55 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@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>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/-wIfkivPxzBElijRN69n3OMN8k8>
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" <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 08:36:07 -0000

Hey Stephen,

On 31 Aug 2015, at 6:48 pm, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> Hi Mark,
> 
> I thought there was also to be a change to say that .onion names would
> in future need to continue to adhere to the DNS name syntax (lengths
> mainly) just so that we don't get more ickkiness when/if .onion names
> are handled by code expecting DNS names?
> 
> That wasn't from the secdir review but came up in the general IETF
> list discussion in the last call.

See:
  https://github.com/mnot/I-D/commit/3b691672b94455f2038353ae03c04c3b1001193d

Note that I just stole that text out of RFC3986. If there's a better way to do it, I'm all ears.

Cheers,



> 
> S.
> 
> On 31/08/15 08:58, Mark Nottingham wrote:
>> Attempting to address all of the outstanding feedback I've seen:
>> 
>> * <https://github.com/mnot/I-D/commit/b3cdbbd0964532c88fefde3786d82b8bee1c62ee> uses .onion "names" instead of "addresses" consistently.
>> 
>> * <https://github.com/mnot/I-D/commit/941719e8de43a642c2fab9049927b60d23b7012d> clarifies the requirements placed upon registrars, as per the IANA review.
>> 
>> * <https://github.com/mnot/I-D/commit/bc57060e84ea338ff107f623b9e43498ee8d8309> updates the Tor URLs, but does NOT flip the two references suggested in Gen-ART to Normative; as per subsequent discussion, they aren't necessary to register the TLD, merely informative. Please advise if I read that wrong.
>> 
>> * <https://github.com/mnot/I-D/commit/358186a82887ed3907537bc45bd37937b4a6a09e> moves much of the generic explanatory text from Security Considerations into the Introduction, as per the SecDir review. 
>> 
>> * <https://github.com/mnot/I-D/commit/ca1eaaec5129f7ce82df8a749c11eb692de1059c> notes what happens when legacy systems get DNS queries leaked to them, as per the SecDir review.
>> 
>> * I didn't yet do anything to address this feedback in the SecDir review:
>> 
>>> Then, the security section also does not discuss how malicious name resolvers could be deployed in order to attack the TOR network. For example, if TOR security relies on DNS servers “black holing” misrouted request to resolve “.onion” names, what happens if malicious servers replace the suggested black-holing with some malicious tampering?
>> 
>> Christian, how would that work? I don't see how this kind of attack (by having a malicious server leverage clients who erroneously forward DNS requests for .onion) is going to be qualitatively different from any other attack on the Tor network; indeed, it doesn't seem like a very effective way to attack the network itself. Now, it may be that you can trick some users into thinking they're on Tor when they're not, in the right circumstances, but that's not an attack on the network. 
>> 
>> Can you give some more detail here (or ideally some suggested text)?
>> 
>> Cheers,
>> 
>> 
>> 
>>> On 30 Aug 2015, at 7:16 am, joel jaeggli <joelja@bogus.com> wrote:
>>> 
>>> On 8/29/15 3:10 AM, Mark Nottingham wrote:
>>> 
>>>> If the IESG would like to set a clear, unambiguous policy about this,
>>>> I'm sure it would be welcomed; personally, I've heard advice both
>>>> ways, and have not yet figured out how to make everyone happy.
>>> 
>>> Well... you can ask me. imho the situation looks like the following to me.
>>> 
>>> I think it's fine to have the discussion, propose the updates and hold
>>> the draft update till the end; or to roll a new version as the product
>>> of the discussion. The former runs the risk of accumulating a discuss
>>> either from me or from another AD due to something that "really needs to
>>> be addressed" prior to exit from iesg review. the later that we need
>>> more time, if it comes shortly before thursday. ( the call is now at
>>> 0700 pacific) so it's extremely unlikely that I will manange to
>>> re-review something submitted late wednesday evening.
>>> 
>>> I'm kind of waiting on the update to the iana language I asked for on
>>> 8/15 and that is a barrier to publication, but I expect we know what
>>> it's going to say in that respect already so I'm not going to hold up
>>> the dicussion on that...
>>> 
>>> thanks
>>> joel
>>> 
>>>> Cheers,
>>>> 
>>>> -- Mark Nottingham   https://www.mnot.net/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

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