Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) UsabilityQuestion

[Andrew Sullivan <ajs@shinkuro.com>]

On Mon, Dec 29, 2008 at 10:31:24AM -0500, Edward Lewis wrote:

> What do you mean by "the private keys for the two sponsors?"
>
> Splitting hairs, the signing of DNS information happens after it leaves 
> the database (of the registry) and before it hits what is currently known 
> as the DNS (the master server).  If a registrant has two operators for 
> DNS (and many do), the operators are either both offering slave service 
> or one is slaving off the other.
>
> IOW, if there are two sources of key-pairs for a domain name, there's  
> trouble elsewhere.
>
> Maybe I don't understand the situation you have in mind.

Suppose I have RegA and RegB, and a registrant with example.org
sponsored by RegA.  RegA also happens to be the DNS operator for
example.org.  Example.org is signed.

If the registrant wants to move to RegB, there's a potential problem.
RegA operates the DNS, and therefore presumably has the private keys
for the current keying material corresponding to the DS record in
.org.  There are a few possibilities I've thought of (in no particular
order): 

1.  Create new keys, publish them in RegA's DNS and as the DS in the
.org DNS, and then use those keys for RegB's DNS as well.  This
requires the registrant to know something about DNS, I expect, and
also requires RegA to present an interface for registrant to send the
key information (and RegA may not have such an interface).

2.  Get RegA to give the private key data to RegB.  This is a bad idea
anyway, and anyway I doubt anyone would co-operate with it.

3.  Co-ordinate the operation (independently) between RegA and RegB.
This requires that every DNSSEC-operating registrar in every registry
have some sort of bilateral communication with every other registrar.
I doubt this will work.

4.  Make it possible for RegB to modify the DNS data of the domain
while the domain is pending transfer.  This strikes me as a very
EPP-like way to do it: the gaining client initiated the transfer, then
sends the update command with the new name servers and key data to the
registry.  The domain is in pendingUpdate _and_ pendingTransfer status
until the transfer is approved, at which point the updates
automatically happen.  If the transfer is refused, then the update
fails as well.  I _think_ this is compatible with the current RFCs,
but I'm not aware of any currently deployed code that works this way.

5.  Go through an insecure phase

6.  RegB obtains the necessary (public) key data from RegA and
publishes all of it in the RegB DNS.  By carefully sequencing the
addition of additional records and removal of old ones, the domain
remains secure the whole time.  This can be made to work today, but I
think it's a little fragile.

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.