Skip to main content

Last Call Review of draft-ietf-dnsop-onion-tld-00
review-ietf-dnsop-onion-tld-00-secdir-lc-huitema-2015-07-30-00

Request Review of draft-ietf-dnsop-onion-tld
Requested revision No specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-08-11
Requested 2015-07-16
Authors Jacob Appelbaum , Alec Muffett
I-D last updated 2015-07-30
Completed reviews Genart Last Call review of -00 by Joel M. Halpern (diff)
Secdir Last Call review of -00 by Christian Huitema (diff)
Opsdir Telechat review of -00 by Tom Taylor (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-dnsop-onion-tld by Security Area Directorate Assigned
Reviewed revision 00 (document currently at 01)
Result Has issues
Completed 2015-07-30
review-ietf-dnsop-onion-tld-00-secdir-lc-huitema-2015-07-30-00
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