.onion

As part of the IETF standards process, our steering group (IESG) recently approved ‘The .onion Special-Use Domain Name’ (draft-ietf-dnsop-onion-tld-01.txt) as a Proposed Standard. Because this might garner attention beyond the usual standard actions, I wanted to briefly summarize some points of the process to date, and share an outcome of the IESG’s discussion that suggests possible future IETF work.

As the technical summary that accompanied the announcement to the IETF community indicated, the approved document uses the Special-Use Domain Names registry established by RFC 6761 to register ‘.onion’ as a special-use name. In effect, ‘.onion’ will be treated in the same way .local, .localhost, and .example have been dealt with previously—that is, outside the global Domain Name System (DNS). Adding .onion to the Special-Use Domain Names registry will also enable hosts on the Tor network to obtain validated SSL certificates.

The registry and the process defined in RFC 6761 for updating it are based in IETF’s responsibility for the DNS standard, and for promoting interoperability among Internet protocols. The reservation followed established IETF processes for open participation and discussion. There is no IETF specification about Tor, but the registration relates to its interaction with DNS.

The approved document is a product of the IETF DNSOP Working Group. Some contention arose during the processing of the document in the working group. There also was some discussion about needing to clarify or adjust RFC 6761 before making any additions.

During its discussions, the IESG considered the existing broad deployment and the potential security impact of not registering .onion as a special name to be important factors. For example, Certificate Authorities (CAs) might stop issuing certificates for .onion names, compromising some users’ ability to use software implementing the Tor protocols. Most importantly, the registration does meet the criteria in RFC 6761 which is our current process.

However, subsequent to this action, the IESG believes RFC 6761 needs action, and substantial community input. It needs to be open for review and modification because the current process is unscalable. Several other names had also been submitted for consideration as special names, and the RFC may not give adequate guidance about how when names should be identified as special names. Special names should also be, as the name implies – special and rare. The DNSOP working group is chartered to address this RFC 6761 review.