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

"Christian Huitema" <huitema@huitema.net> Mon, 20 July 2015 08:09 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 746271A038E for <secdir@ietfa.amsl.com>; Mon, 20 Jul 2015 01:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iVrmUzB5bQou for <secdir@ietfa.amsl.com>; Mon, 20 Jul 2015 01:09:48 -0700 (PDT)
Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4216D1A038D for <secdir@ietf.org>; Mon, 20 Jul 2015 01:09:48 -0700 (PDT)
Received: from [] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ZH68v-00008U-3Q for secdir@ietf.org; Mon, 20 Jul 2015 04:09:47 -0400
Received: (qmail 9617 invoked from network); 20 Jul 2015 08:09:44 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[]) (envelope-sender <huitema@huitema.net>) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-dnsop-onion-tld.all@tools.ietf.org>; 20 Jul 2015 08:09:44 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'The IESG' <iesg@ietf.org>, 'secdir' <secdir@ietf.org>, draft-ietf-dnsop-onion-tld.all@tools.ietf.org
Date: Mon, 20 Jul 2015 10:09:52 +0200
Message-ID: <007601d0c2c3$7615b610$62412230$@huitema.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D0C2D4.399F4960"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdag==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ynpn0h36m5_yORLYQrJjiTFCOK4>
Subject: [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: Mon, 20 Jul 2015 08:09:51 -0000

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