Re: Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 24-01-13 12:08, James Mitchell schreef:
> Interesting draft. I hope that registrars warm to the idea and
> implement it. A few high level questions/comments:

Hi James, thank you for your comments.

> Do you have a plan to encourage registrars to use it such that it
> will see success? Do you have the buy in from existing registrars?

We have discussed 3 possible options for DNSSEC transfers with our
registrars. The most important outcome is that the registrars want to
stay in control of the process, and choosing this method over for
example going insecure during a transfer should be at the sole
discretion of the gaining registrar even during the process. It is an
optional process, not mandatory. (At least not by us, but a registrant
may demand it)
They all agreed though, that at least one secure transfer method
should be implemented by the registry and be available, and the method
described in koch-dnsop-dnssec-operator-change was supported with the
consensus of our registrars. As for buy in, I cannot say what the
promises of our registrars are worth, but most of them told us that
they realize that if they don't implement this on their end for
customers leaving, then they won't have any new satisfying customers
that would come to them.
One proof of buy in that I do have is that Bert Hubert's PowerDNS
(Which has a >50% marketshare in .nl) has recently built a feature in
their DNS software specifically to support this transfer method.

> Keyrelay messages provide the losing registrar with early
> notification of an imminent transfer. Do you foresee any potential
> issues with this, for example the losing registrar attempting to
> (intentionally or accidentally) block or delay the transfer.

Let the market know who that registrar is, and he will certainly loose
customers. Those sort of games don't work out well in the long run I
would say. It happens today, and it will happen in the future. I
aggree keyrelay does give advance notice that a customer may be
leaving, but if you are a good customer, you would have informed your
supplier within the notice period to end your contract anyway wouldn't
you ?

> I would suggest that an error should be returned for uploading a
> key for a domain name sponsored by a registrar who has not
> implemented this extension. Would you consider including reasons
> under which a registry should or should not reject the command?

We do not reject anything, we just relay. In a fixed syntax.

The question you could ask is what harm does it do if a registrar gets
a keyrelay message in it's message queue and does not know how to
handle it, or chooses not to handle it. Should the registry mandate
that he handles it? We don't mandate anything, we just facilitate
registrars that want to do secure transfers. We are no dictator nor god.

As a registry, you could choose not to relay for domains that
currently don't do DNSSEC, but there may be use cases where even a
domain without DNSSEC can benefit from a keyrelay command. For example
if the loosing dns-operator can't sign, but has agreed to pre-publish
his customers future ZSK.

For registries that do want to control their registrar's business
processes, I'm open for suggestions of such error messages, but we
won't ever use them as we just simply do what our customers want us to
do and relay the key. It does nothing to the registration data or status.

> I notice there is no feedback loop from the losing registrar to
> the gaining registrar. I assume that the gaining registrar would
> have to poll the child zone (with its own timeout) to begin
> relevant cache-busting timers?

The feedback loop is over DNS indeed.
The only reason we need this keyrelay command is because we cannot
relay the new key over DNS or any other secure channel. It's
documented in koch-dnsop-dnssec-operator-change

> Note that the losing registrar may not provide DNS services for the
> given domain name. Or do you consider the transfer pending period
> of ample time for caches to expire.

It's the dns-operators and registrars that control that process and
it's timing.
We only describe the EPP syntax because the registry is the middle
man, and communication with the registry is over EPP. Communication
between registrars, registrants and their DNS operators can be over
EPP, but it usually isn't. It's out of scope for this document,
thought we do mention in the security section that that communication
channel should also be authenticated, but it's not to us to mandate how.

> I would assume that a registry may delete an unread keyrelay
> message from the queue should a transfer be completed
> successfully?

That's local policy.
It's not defined in the current EPP RFC's that messages should be
deleted from the message queue by the registry. It's only defined how
a registrar can delete messages from it's queue after he has read them.
As for us, we just leave them there as long as the registrar does not
delete them. They do no harm.

> Some registrars may prefer to process the message queue in batch, 
> potentially increasing the time between submission to the server
> and retrieval by the losing registrar. Do you foresee any need or
> reason for a priority-based, or named message queue to better
> facilitate keyrelay?

If they read their message queue in batch, it's their thing.
How fast registrars or DNS operators should work is not our call.
I think it's their customers that decide if it's a good thing.
A DNSSEC transfer process takes time anyway. And it's not only reading
the queue, it's also what you do with the output and how fast you
provision the relayed key. We have nothing to say about how fast some
DNS operator handles it's customers requests.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email protected]
XMPP: [email protected]
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRAVa9AAoJEDqHrM883Agnw3kIAKaRvRcLoABAVhY3jgbXujqf
TLDM4nYod8mLX7empnpcttBDvcrE3LAKH+CwtMKTR9zSdWZZD9MuvkhikWhWWs3f
illnaHZmfTKnp0+TwpRHF8KsUTgjgUzwMJB9fST2CamBB3mob802GGYqrxpDzqQT
Rna6X9RHM/wzKDBl88yL5OhnufVd2Df7k0wqDcXLeN7xNY1T5nA+OCS6XMtChBr4
CfdkUEWvvTazJmhZ+QifrFzOM2y6OgLfpH/LQEBQstqMRsdEOS9lj4yxAJy9TeVJ
TehtH13BXdfla6A/Z4t6feFDjwdxOVhSWSY7s9R0RvmPBwaDvVGZ9RdMvQEaUuM=
=8dvr
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg