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

Kathleen Moriarty <> Fri, 28 August 2015 14:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A87F61B2CD4; Fri, 28 Aug 2015 07:31:37 -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 n_tCHV_Wr78u; Fri, 28 Aug 2015 07:31:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE77D1AD055; Fri, 28 Aug 2015 07:31:34 -0700 (PDT)
Received: by wicfv10 with SMTP id fv10so9784633wic.1; Fri, 28 Aug 2015 07:31:33 -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=zyeB+UEyDmG2dqtps+5MPTsfFX3+dSqpLTdtoA3Wm/Y=; b=I5veHX9DKKWKitHg8p158a2T8iP/yvWL63qzoy8U4UDcbp6KbZJbLyPGqHcB1BjYj/ oJXq3H0DU/FAD35RDP6OYQGSuXMNfqGMxdIanF0C9w57aUA5nQKy5zvjMawJvOttEoTv 4izYoEBgVToFcQzeYgamyhl0OMAJN968yxx4K87/UK3ThTnHQYc37XJlV9hjnIEcU+Zc +a32Wv1ULOxI9aExbY7PdCq+7NF0353y+EtZMwgz8AIPMgYv+PlPWHFr3BMEpfm0HRCe epwqZaJJj9qIMkpU9quzsvvQ3XCNfNjJh5Q6EfYcCpRXil9ALiNedDjxwKWdCgTsMIUB rPEg==
MIME-Version: 1.0
X-Received: by with SMTP id ld5mr12910657wjc.14.1440772293381; Fri, 28 Aug 2015 07:31:33 -0700 (PDT)
Received: by with HTTP; Fri, 28 Aug 2015 07:31:33 -0700 (PDT)
In-Reply-To: <>
References: <007601d0c2c3$7615b610$62412230$> <> <>
Date: Fri, 28 Aug 2015 10:31:33 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: Alec Muffett <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: secdir <>, Mark Nottingham <>, "" <>, The IESG <>, Brad Hill <>
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: Fri, 28 Aug 2015 14:31:37 -0000


Thanks for getting back to me and Christian.

On Fri, Aug 28, 2015 at 10:10 AM, Alec Muffett <> wrote:
> On Aug 27, 2015, at 21:46, Kathleen Moriarty
> <> wrote:
> Hi,
> I don't see any on list responses to the points Christian raised, have
> they been addressed?
> Hi Kathleen!
> I'm Alec, I am one of the co-authors of the draft.
> At the suggestions of Mark Nottingham & Richard Barnes (cc:) we have
> refrained from issuing revisions to the draft because of the impending
> 2015-09-03 IESG telechat, in order that discussion does not derail for
> pursuit of a moving target; that said, we authors and our helpers and
> experts in IETF process (for whose help we are extremely grateful) have been
> discussing the best ways to address the handful of issues which have been
> raised.

Comments from other ADs are asking about the comments that have not
been addressed.  The effect of this is that the ADs are reviewing and
don't know if outstanding comments from reviewers in last call will be
addressed.  I recommend asking the sponsoring AD if you could upload a
new version today.  I didn't cast my ballot after reading it yet as
the SecDir review wasn't addressed and Christian had some good points.

If we at least had a version to look at that addressed the points, it
would help some of us... even if it's posted elsewhere.

> One question under discussion has included a proposed amendment from IANA
> regards "registration" versus "delegation" and whether the notes kindly
> provided by IANA might, if their suggested amendment were made, cause a lack
> of orthogonality between the draft and other relevant documents. Suzanne
> raised that matter and we feel it's something best discussed and perhaps
> addressed in batch with other changes.

This would be important for all ADs to see.  Although the IESG is
copied on this message, it's a follow on from the SecDir review, so
they may not all read it unfortunately.

> In particular reference to Christian's comments:
> 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.
> That is correct and is the intention, although perhaps my preferred phrasing
> would be "present '.onion' names as if they were subdomains of some other
> domain within an arbitrary top-level domain" - since this is really about
> the existence of Layer 7 proxies attempting to provide 'semi-transparent'
> access to the Tor Onion network as-if the onion namespace were a virtual
> namespace of some corporate enterprise.
> An example of this would be:
> ...which is the (independent, non-Tor) Tor2web organization's link to the
> DuckDuckGo hidden service; the onion address is hidden as the leftmost
> label.
> Precisely the same website is served though another proxy at:
> ...which is a layer 7 proxy run by Seotecs UG in Germany, but whose choice
> of DNS domainname under ".cab" leads to a more obvious risk of confusion.

Do you have proposed text to address the concern about how the
security considerations section is written?

> 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.
> Some bad things are possible, yes - HTTP man in the middle, not least - but
> to my mind the risks are little worse than risks the likes of
> "" would offer, and in fact I believe such risks
> underscore the importance of registering ".onion" so that SSL EV
> certificates can be brought to bear upon the mitigation of some of these
> risks.

I think the question/request here is to more clearly state these
security concerns so that the security considerations are a bit more

> 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.
> Incorrect; the main reason for registration of ".onion" is CA/B-Forum Ballot
> 144:
> ...which permits the existence of SSL Certificates for Onion addresses until
> 1 November 2015.
> If (upon that date) the ".onion" namespace has not been recognized as a
> global TLD, all SSL certificates for the ".onion" namespace will be killed
> and SSL will no longer be able to mitigate these threats for Onion sites.
> This will lead to the shutdown of the Facebook ".onion" site, another that
> is owned by, and the SSL service for The Intercept magazine,
> amongst others.

OK, can you propose text to clarify this point?

> Thus, my motivation.
> 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.

Understanding and seeing the proposed changes would help a lot for my review.

> Per the comments above, a draft explanation of Onion address syntax
> (summary: they will remain compatible with DNS syntax) is with Mark and
> Richard for discussion but is on hold for the reasons explained above.
> Regards Onion name "resolution", we believe that that matter is best dealt
> with outside the scope of this document, not least because the resolution
> mechanism is defined by software which is open to change.
> It seems more important to confirm that Onion addresses will remain legal
> within the constrains of DNS label syntax.
> The security section also does not explain how the “leakage of names” issue
> is mitigated for legacy systems.
> Simple: it's not.  The goal of leak-reduction is to reduce leaks, rather
> than to assure security.

OK, stating this would hep to make the security considerations section
more complete.

> There certainly is leakage of lookups for the ".onion" TLD to the root
> servers, and eliminating that 100% is unlikely, but it is a wasteful thing
> and should be inhibited for reasons of hygiene rather than security.
> 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.
> Agreed. That's never been the intent of the document, thus it should be
> fine.
> 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?
> Tor security does not rely on blackholing DNS requests, it relies upon
> cryptographic technology.
> Tools which are Tor-aware will not have the leakage problem.
> Tools which make a half-assed approach towards Tor access  by passing names
> through DNS resolution should be encouraged towards failure, but it is not
> required for security.

I think a discussion on this in the security considerations could be
helpful.  I see your pints when systems behave as expected and are TOR
aware, but also Christian's points on possible malicious use.  It's
helpful to put out the full set of considerations in a draft for
future readers who won't see this thread.

Thank you!
>     - alec
> --
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London


Best regards,