-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi All,
I have drafted some new proposed text for section 4.4.5 of RFC4641bis.
I tried to bring some more structure to the section while maintaining most of
the text from the current iteration of the document.
It now clearly separates:
- -Definition of terms
- -Problem statement
- -3 possible solutions for specific use cases.
I also tried to stick with a correct definition of terms and not mix up the
roles of DNS operator and registrar.
I've included some wording about timing issues to have a step by step guide.
I would like to have some discussion on:
- -Are they actually correct ?
- -Do they need to be covered here or in draft-morris-dnsop-dnssec-key-timing ?
(should they be mentioned here in brief with a detailed explanation in
draft-morris-dnsop-dnssec-key-timing, or should they be left out all together)
4.4.5. Changing DNS operator
The parent-child relation is often described in terms of a (thin)
registry model. Where a registry maintains the parent zone, and the
registrant (the user of the child-domain name), deals with the
registry through an intermediary called a registrar. (See [12] for a
comprehensive definition). Registrants may out-source the
maintenance of their DNS system, including the maintenance of DNSSEC
key material, to the registrar or to another third party DNS operator.
The entity that has control over the DNS zone and its keys may prevent
the registrant to make a timely move to a different DNS operator.
There are multiple reasons why a registrant may want to change it's
DNS operator. Where most transactions that need administrative action
at the parent by a registrar are business driven, not all transactions
necessarily include a change of DNS operator. When a transaction does
include a change of DNS operator for a child zone, there are in theory,
3 ways to accommodate such a transfer.
The problems that arises during a DNS operator change is when a
validator tries to validate records from the new zone with the losing
DNS operator's key and there is no signature material produced with this
key available in the delegation path after redelegation from the losing
to gaining DNS operator has taken place. One could imagine a rollover
scenario where the gaining DNS operator pulls all RRSIGs created by the
losing DNS operator and publishes those in conjunction with its own
signatures, but that would not allow any changes in the zone content.
Since a redelegation took place the NS RRset has -- per definition--
changed so such rollover scenario will not work. Besides if zone
transfers are not allowed by the losing DNS operator and NSEC3 is
deployed in the zone then the gaining DNS operator will not have
certainty that all of the losing operator's RRSIGs are transferred.
The first option to accommodate a transfer is to become insecure.
The registrant of the child-domain can order the registry through the
registrar to remove the DS record at the parent zone. Once the DNSKEY
has disappeared from caches, so 1 DNSKEY TTL after the parent has
removed the DS key, the delegation at the parent can be changed to a
new NS set from the gaining DNS operator, and the domain can be signed
again with the new key material from the gaining DNS operator.
In an extreme case where the losing DNS operator is obstructive and
publishes a DNSKEY RR with a high TTL and corresponding signature
validity, the losing DNS operator's DNSKEY could end up in caches for,
in theory, tens of years.
So this option is only viable for low profile domains that can afford to
become insecure for a DNSKEY TTL period. During this transfer period
there is a possible attack window, which makes this option not advisable
for important high profile domains that cannot afford to become insecure.
The second option is to sign the zone at the gaining DNS operator with
the existing keys from the losing DNS operator. This option is purely
theoretical, and should not be used in an operational environment since
it implies exposing the private keying material when it is handed over
from the losing to the gaining DNS operator. In practice, when using
Hardware Signing Machines (HSM's) it is not even possible to extract
the private keys from the machines, which only leaves the option of
physically moving the machines from one operator to another. Under
normal circumstances this is not very realistic nor scalable. The
option is only documented here to be complete.
After signing the new zone at the gaining DNS operator, the delegation
can be changed at the parent. It is advisable to do a KSK-rollover
after the transfer has completed and the old NS set from the losing
DNS operator has disappeared from caches, so 1 NS TTL from the old zone
after the losing operator has stopped serving the old zone or is
