-----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 serving the new zone as secondary. The third option is that the losing DNS operator signs the gaining operator's public keys. In a cooperating environment one could proceed with a pre-publish ZSK rollover whereby the losing DNS operator pre-publishes the ZSK of the gaining DNS operator, combined with a double signature KSK rollover where the two DNS operators exchange public keys and independently generate a signature over the keysets that they combine and both publish in the zone. During the key rollover, the delegation can be changed at the parent. Sticky resolvers can still point to the losing registrar's zone, so it is advisable that the losing DNS operator is serving the new zone as secondary for at least 1 NS TTL, or stops serving the old zone after the rollover. All three options require the losing DNS operator to cooperate in the transfer process to some extend for the domain to work. This is because with DNSSEC only one version of the truth can be validated by one single trust anchor, where in the non DNSSEC world 2 or even more versions of the truth are accepted by a non DNSSEC resolver. The mandating of the cooperation by the losing DNS operator can either be handled by the parent of the zone in registration policy, or in a bilateral contract between the registrant and the DNS operator when the registrant outsources it's DNS operations for his zone. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschu...@sidn.nl W http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBShP2GDqHrM883AgnAQj+Mgf/QDoJHWQO0idsqlzLPBz/ho+g9jPX+Uql hPo/afhHkSbgsBW2e0yRdA3OB6y2MofaiWtg1ACBXU7yzVpM2PiCU36IBacms14r YELcJbTGv3KJjDNexjQ1DaejVJ1xnJXqoKNVt0SSYY8jbsT0KaOJB/NgQSM0TAFs +E0jDqcsyTAxoDuMjtYKSiZhk39xaZuJXu6nATxnDW2KZ5FJCPIAwiZvpRlrM+0g t5jc/07Lokm2Rd+WphR0tbJL8iI1EVDJrDyywi9ztwpUMpNpBHGnCRD4v7LSy7vL 4dl/w8kV5iJSReP4cPhFXeGf0Rw//ps+/pGcRXqEd9MChdQn7WOIlg== =7VGd -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
