This blogpost was originally published here. As a regular reader of my blog (if not: shame on you!) you'll notice this in the wording as it was moderated and translated by our communications department. However if you have found the easter egg let me know.
In June 2016, I wrote a blog about the impending publication of the key relay standard. I can now report that the standard has finally been published by the IETF as RFC8063, entitled Key Relay Mapping for the Extensible Provisioning Protocol.
What is key relay again?
EPP is an XML-based protocol used for interacting with a registry to register domain names and update registration data. So, for example, registrars use it to interact with SIDN, the registry for .nl. More than 90 percent of all transactions involving .nl domain names are carried out by registrars using EPP to communicate with our Domain Registration System. In itself, EPP isn't very exciting. It's primarily an XML specification defining the syntax of the messages that registries and registrars need to exchange. The interesting part is what you can do with it.
SIDN is one of the first registries to have worked with the registrar community to successfully roll out DNSSEC on a large scale. As far back as 2011, we flagged up a problem: if you transfer a domain name that's secured with DNSSEC from one registrar to another, its security has to be temporarily interrupted. In other words, the transfer process isn't secure. For the transfer to be secure, the 'chain of trust' has to remain intact throughout. For details, see the earlier publication on this topic by SIDN Labs.
SIDN wanted to make secure transfers possible by providing the missing link needed to keep the chain of trust intact. The rationale for doing so being that secure transfers help to make the internet safer.
Why has it taken so long?
Like many standardisation initiatives, the process of getting the new internet standard published has been a long one. It was back in the summer of 2015, at the 93rd IETF meeting, that the EPP working group approved the document. After that, the document was referred to the IESG (a sort of steering group) for review. That involved looking at the technical interoperability, whether the working group had followed the correct procedure, and so on. An IESG review usually takes about six weeks, but in this case it took a year. The main reason for the delay is that an Intellectual Property Rights Disclosure (IPR Disclosure) applies to the document.
Held up by a patent application or by the working group?
An IPR Disclosure implies that an IETF member had reported that the proposed standard may infringe an existing patent or one that's been applied for. In the case of key relay, the issue was that Verisign had applied for a patent on a method for transferring the DNSSEC key material linked to a domain name. Key relay wasn't the only standard affected by the IPR Disclosure in question: all proposals referring to 'secure transfer' were held up.
IPR Disclosures are a sensitive issue within the IETF. The internet works on the basis of open standards, i.e. standards that anyone can use freely. A lot of people don't like the idea of standards that are – or may be – covered by patents. Especially where the aim is to increase the security and stability of the internet. So, if you study the small print of the standardisation process, you'll find that an IPR Disclosure doesn't prevent standardisation going ahead. However, the working group has to make it clear that it has made a considered decision to proceed with publication.
We began by trying to find out what Verisign planned to do with its patent. If the patent application was approved, was anyone that infringed the patent liable to be sued by Verisign? Or would they have the opportunity to buy a licence allowing them to go on using the technology and, if so, subject to what conditions?
Over a period of about a year, we made various attempts to get an answer from Verisign, but the company was unwilling or unable to provide clarification. So, in the end, we (the authors) decided to press ahead with the publication process. The main reason was that we really wanted to enable secure transfers, so as to make the internet more secure and more reliable. For the standard to be published, the working group had to make a statement confirming that approval of the document was the outcome of a considered decision-making process.
Persuading the working group to make such a statement proved difficult as well, because many members were reluctant to act while the patent application was still pending. The working group's US members were particularly reticent about participating in the debate. Ultimately, however, various people came out in favour of publication, leading to the IESG approving the document for publication.
What next?
Now that the standard is in place, we want to promote its adoption. Registries all over the world can now transfer domain names securely, by following a uniform EPP-based procedure. However, before we press ahead on that front, we need to bring our own implementation into line with the published standard.
Early in the standardisation process, back in November 2013, we implemented an initial version of the key relay extension in the DRS. That version was used to perform the world's first successful secure transfer.
Since then, the XML syntax has been modified as part of the standardisation process. The version of the standard used by our registration system now needs to be revised to reflect the syntax changes. Once that's been done, we'll be working with the registrar community to see how we can encourage the use of secure transfers. Because we won't have made a real contribution to the quality and security of the internet until the standard is in widespread use.
References
[1] https://www.sidnlabs.nl/wp_2013_EPP-keyrelay_v1.pdf
[2] https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/
[3] http://www.dnssec.nl/cases/dnssec-secure-transfers-het-kan-wel.html
[4] https://datatracker.ietf.org/doc/draft-koch-dnsop-dnssec-operator-change/