Subject: [DNSOP] RFC4641bis Section 4.4.5 proposed new text

From: "Antoin Verschuren" <[email-masked]>
Date: Wed, 20 May 2009 14:22:48 +0200

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 [email-masked]
W http://www.sidn.nl/

---

From: Scott Rose <[email-masked]>
Date: Wed, 20 May 2009 13:20:26 -0400

Antoin Verschuren wrote:
> -Definition of terms
> -Problem statement
> -3 possible solutions for specific use cases.
> -Are they actually correct ?
> -Do they need to be covered here or in draft-morris-dnsop-dnssec-key-timing ?

Looks ok to me - at least I haven't thought of anything wrong with it at
the moment :)

I would prefer them here simply to make life easier - non-DNS-geeks will
want to read 1 guide, not a bunch of RFC's.  So I would really go with
"mention here in brief with the ref to
draft-morris-dnsops-dnssec-key-timing".

Scott

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 May 2009 12:03:01 +0200

>    There are multiple reasons why a registrant may want to change it's

"its"?  "their?"

>    certainty that all of the losing operator's RRSIGs are transferred.

But you need that data anyway, to continue providing the content of
the zone.  So you can also provide for RRSIGs.

But as you pointed, it's not going to help because the signature on
the NS RRset has to change.

>    Hardware Signing Machines (HSM's) it is not even possible to extract

"Hardware Security Modules (HSMs)" (see the previous discussion).

Moreover, the same key could be used for multiple zones, for different
customers.

>    outsources it's DNS operations for his zone.

I think it's been proposed to lock NS/DS records in the resolver to
address this problem.  Other resolver-side mitigation mechanisms are a
side effect of dealing with the unsigned referral/glue issue.  After
all, if you've never validated the NS RRset and its addresses, a
registrar switch is indistinguishable from a previously unnoticed
attack based on a spoofed referral.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99