[Opendnssec-develop] Zone moving between operators

[John Dickinson]

On 23 Mar 2009, at 20:46, Antoin Verschuren wrote:

> Op maandag 23-03-2009 om 19:09 uur [tijdzone +0000], schreef John
> Dickinson:
>> On 23 Mar 2009, at 18:54, Matthijs Mekking wrote:
>>>
>>> * What to do when a zone moves from one operator to another.
>>
>> Several people have asked me this as well - Off the top of my head, I
>> don't think we can do anything. There are too many variables. I think
>> that unless you (as a registrant) are willing to test the interaction
>> between operators on a regular basis you have to assume that you will
>> go, or at least will risk going, unsigned at change over.
>
> In current economics, the answer "we can't" won't help to get DNSSEC
> deployed. If my choice is between not signing my zone or disappoint my
> clients when I'm changing infrastructure, I know I will choose to not
> sign. Changing infrastructure is a common thing in current business
> processes, and in some countries even a requirement in policy.
>
> I think we can do it.
> Moving a zone has 3 options:
> 1. Become insecure, like you say.
> 2. Hand over the private keys for the zone to the new operator so he  
> can
> do a key rollover to use his own keys. Not a very safe proces and
> certainly not possible when you use certain HSM's.
> 3. Have the losing operator sign the new key(s) from the gaining
> operator during a special key rollover process. I think that it's
> doable.
>
> Disadvantage of the last 2 is that it needs cooperation of the losing
> operator. But that's politics or policy, but I think it must be  
> possible
> to change infrastructure without becoming insecure for DNSSEC to  
> become
> deployed.

It is possible as long as the two operators will cooperate.  
Cooperation is better solved by good process and rules not by  
technology. In option 3
1. The new operator would have to send a DNSKEY RRs for new KSK and  
ZSK to the zone owner.
2. The zone owner would have to send them to the old operator to be  
included in the zone.
3. This would have to happen at some time T before the old operator  
stops signing or publishing the zone.
4. key rollover process would occur...

IMHO the biggest issue here is that we would need two competent,  
cooperating operators and the zone owner would have to understand what  
was going on. All that OpenDNSSEC can do is provide a mechanism for  
the new operator to export a DNSKEY RR for a new zone (possibly before  
they are actually signing it). I will add that to the requirements.

Actually solving this issue is more about education and training. TLDs  
might want to document this in detail and offer training courses for  
registrars. Also they could offer advice to registrants on issues like  
these that they may want to explore when selecting a registrar.

If you mean that OpenDNSSEC should provide a mechanism for the  
cooperating operators to exchange DNSKEY RRs directly then I suppose  
we could. It will only work if all operators are using OpenDNSSEC or  
we standardize the API. I don't really want to go down this path but  
AFAIK nothing we are doing now will prevent this from being done in  
the future.

>
>>> * What to do when the HSM is replaced
>>
>> Just works (I hope). You add a new HSM, update policies to start  
>> using
>> it and new keys will be created in the new HSM.
>
> Here you actually have the same issue as you have in option 3 above.
> You need the old HSM to sign the new keys that are generated by the  
> new
> HSM if you cannot move the private keys around from HSMold to HSMnew.
> You cannot just start using a new keyset that was not signed by the  
> old
> one because you will break the chain of trust for signatures that are
> still in caches.

But you control both HSMs - so keep the old one round long enough to  
do this. If it has failed then go to your backup.

>
>
>>> And does KASP has the logic
>>> if a key for zone A needs to be rollovered, but must be kept for  
>>> other
>>> zones.
>>
>> No - lets not go there. :)
>
> I prefer not to go there as well, but as it is common business  
> practice
> to move one zone from operator 1 to operator 2 without moving all the
> other zones from operator 1, the advice should be to use a key per  
> zone,
> and not reuse keys.

Yes and sharing keys between zones is only an option.

John
---
John Dickinson
http://www.jadickinson.co.uk