rikribbers.nl — Key relay: keeping the DNSSEC chain intact during transfers

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.

At long last, we are nearly there. Key relay, an internet standard developed by SIDN, will soon be published as an RFC by the Internet Engineering Task Force (IETF). As one of the standard's authors, I shall take great satisfaction from seeing that milestone reached. However, publication of the new standard is far from the end of the story. The next challenge is to get the standard adopted by the market.

What is the new internet standard?

One of the challenges associated with DNSSEC arises when a domain name's registrant decides to change DNS operators. Ideally, DNSSEC validation should remain possible throughout the transfer. A transfer that allows that is referred to as a 'secure transfer'.

A secure transfer depends the DNS operators being able to securely exchange DNSSEC keys (see [1]). SIDN has accordingly developed an internet standard that defines a secure key exchange mechanism based on the EPP protocol. [2].

alt Some picture to cheer things up!

In this blog post, I explain how to perform a secure domain name transfer using EPP and the new internet standard. The emphasis is on how the procedure should be implemented in EPP.

Where the .nl zone is concerned, most DNS operators are also registrars. Consequently, the key relay standard is an ideal basis for exchanging DNSSEC keys, because all registrars have a relationship with the registry and access to a familiar, secure EPP channel for the communication of key material.

The standard is currently in the final phase of adoption by the IETF. We expect it to be published as an RFC in two to three months.

Transfers within the .nl zone

The key relay standard defines a procedure that allows the registrant of a secure domain name to change registrars without interrupting the name's security.

A study of our registration system reveals various scenarios in which DNSSEC security is interrupted, resulting in an insecure transfer. A few examples:

When a domain name is transferred, the new registrar immediately deletes the key material and links new DNSSEC keys to the domain name.
When a domain name is transferred, the new registrar leaves the existing DNSSEC keys linked to the domain name.
Immediately after issuing the transfer token for a domain name, the releasing registrar deletes all the DNSSEC keys linked to the name.

In practice, numerous scenarios arise, in addition to the three outlined above. Following a transfer, some registrars execute a series of separate EPP transactions to link the appropriate data to the domain name.

Under any of the scenarios, there will be a period during which either the DNSSEC chain is incomplete, or validating resolvers are unable to resolve the domain name because the DNSSEC chain is invalid.

Secure transfer: what happens at EPP level?

The secure transfer process has been described at the DNS level in other publications (see [3] and [4]). A number of 'time to live' values (TTLs) have an important function in the process. The DNS level is not considered further in this blog.

A secure transfer involves a number of EPP transactions performed sequentially.

Step 1: The receiving registrar starts the transfer process

The transfer process starts when a registrant asks a registrar to transfer a domain name and provides the transfer token. First, new DNSSEC material is generated and added to the new zone. Then the registrar sends the registry a key relay message specifying the domain name, the token and the new DNSSEC keys.

A specimen EPP key relay message:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:    xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
C:  xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
C:  xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
C:  <command>
C:    <create>
C:      <keyrelay:create>
C:        <keyrelay:name>example.nl</keyrelay:name>
C:        <keyrelay:authInfo>
C:          <d:pw>JnVdBAZxSxZj</d:pw>
C:        </keyrelay:authInfo>
C:        <keyrelay:keyRelayData>
C:          <keyrelay:keyData>
C:            <s:flags>256</s:flags>
C:            <s:protocol>3</s:protocol>
C:            <s:alg>8</s:alg>
C:            <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
C:          </keyrelay:keyData>
C:          <keyrelay:expiry>
C:            <keyrelay:relative>P1M13D</keyrelay:relative>
C:          </keyrelay:expiry>
C:        </keyrelay:keyRelayData>
C:      </keyrelay:create>
C:    </create>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Step 2: The registry forwards the new DNSSEC material

The registry checks the token in the incoming key relay request and, if it is correct, places the message in the existing registrar's poll queue. At this stage, no changes are made to the registration. The registry merely acts as an intermediary, enabling the new DNSSEC keys to be passed from one registrar to the other.

The key relay standard is designed so that a registrar needs to know only the domain name and the token in order to send a relay request to the registry. The registrar initiating the transfer of a secure domain name does not therefore have to establish who the existing registrar is, and the registry already knows.

The outcome is a message in the existing registrar's EPP poll queue, as follows:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:    xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
S:  xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
S:  xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
S:  <response>
S:    <result code="1301">
S:      <msg>Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ count="5" id="12345">
S:      <qDate>1999-04-04T22:01:00.0Z</qDate>
S:      <msg>Keyrelay action completed successfully.</msg> 
S:    </msgQ>
S:    <resData>
S:      <keyrelay:infData>
S:        <keyrelay:name>example.nl</keyrelay:name>
S:        <keyrelay:authInfo>
S:          <d:pw>JnVdBAZxSxZj </d:pw>
S:        </keyrelay:authInfo>
S:        <keyrelay:keyRelayData>
S:          <keyrelay:keyData>
S:            <s:flags>256</s:flags>
S:            <s:protocol>3</s:protocol>
S:            <s:alg>8</s:alg>
S:            <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
S:          </keyrelay:keyData>
S:          <keyrelay:expiry>
S:            <keyrelay:relative>P1M13D</keyrelay:relative>
S:          </keyrelay:expiry>
S:        </keyrelay:keyRelayData>
S:        <keyrelay:crDate>
S:          1999-04-04T22:01:00.0Z
S:        </keyrelay:crDate>
S:        <keyrelay:reID>
S:          ClientX
S:        </keyrelay:reID>
S:        <keyrelay:acID>
S:          ClientY
S:        </keyrelay:acID>
S:      </keyrelay:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-ZYX</svTRID>
S:    </trID>
S:  </response>
S:</epp>

Step 3: The existing registrar processes the poll message

Upon receipt of a key relay message from the registry, the existing registrar adds the new DNSSEC keys to the existing keys on the name server. The registrar then signs the new keys with their own keys, enabling the new keys to be included in the DNSSEC chain.

Step 4: The transfer is executed

In most cases, a 'normal' transfer involves two transactions: the first being the transfer of the domain name to the requesting registrar and the second being an update to the registration data following the transfer.

A domain name transfer request takes the following form:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <domain:transfer
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.nl</domain:name>
C:        <domain:period unit="y">1</domain:period>
C:        <domain:authInfo>
C:          <domain:pw roid="JD1234-REP">JnVdBAZxSxZj </domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Because of the timing issues referred to earlier, it is important that the DNSSEC chain is not modified before the domain name is updated. Only administrative and name server changes are permitted.

A domain name update request takes the following form:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.nl</domain:name>
C:        <domain:add>
C:          <domain:ns>
C:            <domain:hostObj>ns1.registrar2.nl</domain:hostObj>
C:            <domain:hostObj>ns2.registrar2.nl</domain:hostObj>
C:          </domain:ns>
C:        </domain:add>
C:        <domain:rem>
C:          <domain:ns>
C:            <domain:hostObj>ns1.registrar1.nl</domain:hostObj>
C:            <domain:hostObj>ns2.registrar1.nl</domain:hostObj>
C:          </domain:ns>
C:        </domain:rem>
C:      </domain:update>
C:    </update>
C:    <clTRID>500100-002</clTRID>
C:  </command>
C:</epp>

Step 5: The old keys are deleted

Once all the TTLs in the DNS have expired, the new registrar can amend the DNSSEC chain by deleting the old registrar's keys.

For the new registrar, that implies performing an EPP transaction simply to delete the old keys. That is done using the EPP 'remove all' flag. The new keys have to be resubmitted in same message. Once the old keys have been deleted, the secure transfer is complete.

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <secDNS:update urgent="true"
C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C:        <secDNS:rem>
C:          <secDNS:all>true</secDNS:all>
C:        </secDNS:rem>
C:        <secDNS:add>
C:          <secDNS:keyData>
C:            <secDNS:flags>256</secDNS:flags>
C:            <secDNS:protocol>3</secDNS:protocol>
C:            <secDNS:alg>8</secDNS:alg>
C:            <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
C:          </secDNS:keyData>
C:        </secDNS:add>
C:      </secDNS:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

What happens after publication?

SIDN has been using the first version of key relay since July 2013. We introduced it mainly to demonstrate that the system worked [3]. Since then, there has been a lot of discussion within the IETF regarding the standard's XML structure, which has been revised in line with the workgroup's wishes. SIDN is waiting for the definitive internet standard to be published before amending its own implementation, since that will require a DRS EPP interface update.

Once our implementation has been harmonised with the finalised standard, it will be up to the registrars to start using secure the transfer mechanism. As DNSSEC validating resolvers enter increasingly widespread use, being able to transfer domain names securely is rapidly becoming a priority. SIDN will be working with the Registrars' Association to identify ways of encouraging adoption.

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/