Last Call Review of draft-ietf-dnsop-onion-tld-00

Request Review of draft-ietf-dnsop-onion-tld
Requested rev. 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
Draft last updated 2015-07-30
Completed reviews Genart Last Call review of -00 by Joel 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
Review review-ietf-dnsop-onion-tld-00-secdir-lc-huitema-2015-07-30
Reviewed rev. 00 (document currently at 01)
Review result Has Issues
Review completed: 2015-07-30


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