• Banishing the bane of bufferbloat

    Bufferbloat affects everyone who uses the Internet, resulting in frustratingly slow web browsing, laggy video calls, and overall poor quality of experience for Internet users and there's a lot of work underway in the IETF to address it.

    • Bjørn Ivar TeigenIETF Participant
    23 May 2023

  • IETF 116 post-meeting survey

    IETF 116 Yokohama was held 25-31 March 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    26 Apr 2023

  • Reducing IETF Meeting Scheduling Conflicts

    With many IETF participants active across a number of active working groups and limited time slots in an IETF meeting week, we aim to arrange sessions in the agenda to minimize conflicts that prevent participants from joining sessions that are of interest to them. In each post-meeting survey we ask meeting participants to comment on the scheduling conflicts they experienced in the meeting agenda and we then use this information to improve the meeting agenda.

    • Alexa MorrisIETF Managing Director
    1 Apr 2023

  • Messaging Layer Security: Secure and Usable End-to-End Encryption

    The IETF has approved publication of Messaging Layer Security (MLS), a new standard for end-to-end security that will make it easy for apps to provide the highest level of security to their users. End-to-end encryption is an increasingly important security feature in Internet applications. It keeps users’ information safe even if the cloud service they’re using has been breached.

    • Nick SullivanMLS Working Group Chair
    • Sean TurnerMLS Working Group Chair
    29 Mar 2023

  • Next steps towards a net zero IETF

    Built with input from the IETF community, we now have an initial approach and tools for calculating the IETF’s carbon footprint and a strategy for carbon offsetting. For 2023, we will implement this approach with data already available and seek to further improve it for future years.

    • Greg WoodIETF LLC Director of Communications and Operations
    22 Mar 2023
  • Show all

Filter by topic and date

Filter by topic and date

.onion

  • Jari ArkkoIETF Chair

10 Sep 2015

The IETF community approved document using the Special-Use Domain Names registry established by RFC 6761 to register ‘.onion’ as a special-use name.

.onion image

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.

Share this page