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

"Christian Huitema" <> Mon, 31 August 2015 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EFFC81A1BB9 for <>; Mon, 31 Aug 2015 09:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aajMBp8s9bBd for <>; Mon, 31 Aug 2015 09:59:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 699B11A0423 for <>; Mon, 31 Aug 2015 09:59:15 -0700 (PDT)
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1ZWSQH-0000vs-U5 for; Mon, 31 Aug 2015 12:59:14 -0400
Received: (qmail 25805 invoked from network); 31 Aug 2015 16:59:09 -0000
Received: from unknown (HELO huitema1) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 31 Aug 2015 16:59:08 -0000
From: Christian Huitema <>
To: 'Mark Nottingham' <>, 'joel jaeggli' <>
References: <007601d0c2c3$7615b610$62412230$> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 31 Aug 2015 09:59:11 -0700
Message-ID: <003001d0e40e$5ce522e0$16af68a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQI50R8PuDN5FgYzzyJG3m5SgMEMYAJVzMtaAgL9VGEBO6r6yQGDmJGEAalbUnsCAexJawG5pZLqnPCN91A=
Content-Language: en-us
Archived-At: <>
Cc: 'secdir' <>, 'Alec Muffett' <>, 'Kathleen Moriarty' <>,, 'Brad Hill' <>, 'The IESG' <>, '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 16:59:21 -0000

On Monday, August 31, 2015 12:58 AM, Mark Nottingham wrote:
> * <
> D/commit/358186a82887ed3907537bc45bd37937b4a6a09e> moves much of
> the generic explanatory text from Security Considerations into the
> Introduction, as per the SecDir review.

Good edit, thanks.
> * <
> D/commit/ca1eaaec5129f7ce82df8a749c11eb692de1059c> notes what
> happens when legacy systems get DNS queries leaked to them, as per the
> SecDir review.

The summary being, "if a legacy client mistakenly sends a DNS query for a
.onion name to a DNS resolver, the TOR security checks will prevent server
impersonation, but the client will have disclosed the intent to use the TOR
network to reach a specific service." The way I understand it, there are
parts of the world where disclosing such activity is plus plus not good,
correct? A mitigation for such leaks would be having the client's DNS
software act as a backstop and drop any request to a .onion name, without
relaying them.

> * 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
> 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
> a malicious server leverage clients who erroneously forward DNS requests
> .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.

How about:

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.

-- Christian Huitema