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

Stephen Farrell <> Mon, 31 August 2015 08:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7B15B1B30BB; Mon, 31 Aug 2015 01:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DTa0h6m2_0yh; Mon, 31 Aug 2015 01:48:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD8CC1B30A8; Mon, 31 Aug 2015 01:48:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13D7DBE58; Mon, 31 Aug 2015 09:48:24 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xbGCLXmOIox6; Mon, 31 Aug 2015 09:48:23 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id D42A5BE55; Mon, 31 Aug 2015 09:48:23 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1441010903; bh=9ipUnXtXaumOd3gONwZixpK+0JjCzY27BGuUMPHTM/8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=yCOXWM0yxKREXNrZ9GNCQw3lPM7IZZSAKX0hAdrFfyQNmFhnOn+E7bvEbbrdQnDU5 2HBsxLppB9v6HZ5HzM9VATPuJmy8w1da5LXzjUdmcM5jLUmOLC8Pzk4hXM/vUIFm0x 65R7n+VARM/vV110fadMYPV0PYzJIG+w8nAEKIXU=
To: Mark Nottingham <>, joel jaeggli <>
References: <007601d0c2c3$7615b610$62412230$> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Mon, 31 Aug 2015 09:48:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: secdir <>, Alec Muffett <>, Kathleen Moriarty <>, "" <>, The IESG <>, Brad Hill <>, Barry Leiba <>
Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2015 08:48:30 -0000

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.


On 31/08/15 08:58, Mark Nottingham wrote:
> Attempting to address all of the outstanding feedback I've seen:
> * <> uses .onion "names" instead of "addresses" consistently.
> * <> clarifies the requirements placed upon registrars, as per the IANA review.
> * <> 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.
> * <> moves much of the generic explanatory text from Security Considerations into the Introduction, as per the SecDir review. 
> * <> 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 <> 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
> --
> Mark Nottingham