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

Kathleen Moriarty <> Thu, 27 August 2015 20:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACAF51AC406; Thu, 27 Aug 2015 13:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uik3pI5p66nP; Thu, 27 Aug 2015 13:46:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2D181A92F1; Thu, 27 Aug 2015 13:46:38 -0700 (PDT)
Received: by wicgk12 with SMTP id gk12so3347546wic.1; Thu, 27 Aug 2015 13:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ALDAET+XWWQ3JqbNJMyr9XK8m66JK5yEmpSI4/ZHfPw=; b=FdBkn6lDon4/yoXwCL6NIHw0bnzz43io4M6GbKQK6A7htFriGH4QH6WGy1L18E/Yx3 jHDyyaixpJa9oaOPE+4QsWGQFSSuDJh9oPEAbZvYUwlVNLgGgRmKPoVljVwvX8iBZKph ytmjZigNfHiYBKYZLchE5fl5jtCQDXE5+7N2FiyiH+7XC16ZK+2imWlcamYaEb40R9km 5GDh/OwHvNG2tWF5W6YnNOYoeZUo97vqLISYa91Uz2RBVf2/Y0vYv80BDbInmHeJ2jN2 nxn7+B7/OPFYtnmfNdhBxDy/kdAW86QO6MovXS+EF7B5OG8U1Ei72cOFrtG3nH/+CfOD HGTA==
MIME-Version: 1.0
X-Received: by with SMTP id 9mr6798251wjq.95.1440708397650; Thu, 27 Aug 2015 13:46:37 -0700 (PDT)
Received: by with HTTP; Thu, 27 Aug 2015 13:46:37 -0700 (PDT)
In-Reply-To: <007601d0c2c3$7615b610$62412230$>
References: <007601d0c2c3$7615b610$62412230$>
Date: Thu, 27 Aug 2015 16:46:37 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: Christian Huitema <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc:, The IESG <>, secdir <>
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: Thu, 27 Aug 2015 20:46:43 -0000


I don't see any on list responses to the points Christian raised, have
they been addressed?

Thank you,

On Mon, Jul 20, 2015 at 4:09 AM, Christian Huitema <> wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> The document proposes to reserve the “.onion” TLD for special use by the TOR
> project. The document is short and easy to read, went through the last call
> process, and is probably ready to publish. I just wish there was a clearer
> structure to the security section.
> I am a bit puzzled by the way the security section is written. Since the
> purpose of the draft is to reserve the “.onion” TLD, I would expect the
> security section to present the security issues mitigated or introduced by
> this TLD reservation. As far as I understand, the main security issues come
> from client confusion, which could cause “.onion” names to be resolved
> through the standard DNS process. A number of bad things happen then, from
> simple information disclosure that a client is trying to access a TOR
> service, to potential spoofing of secure TOR services. In fact, the main
> reason for the registration request is to mitigate these security issues, by
> requesting that standard DNS resolvers and servers recognize “.onion”
> requests and refuse to forward them.
> The security section makes all these points, but it also mixes in a
> description of the structure of .onion names and their cryptographic
> components. I believe the issues would be easier to understand if the main
> body of the document included a short description of the TOR naming process
> and name resolution.
> The security section also does not explain how the “leakage of names” issue
> is mitigated for legacy systems. By definition, these systems have not been
> updated and do not perform special treatment of “.onion” names. The TLD
> reservation probably helps somewhat, but this is not discussed.
> 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 Huitema


Best regards,