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

Antoin,

The draft looks to be a good starting point.  Below is some feedback which overlaps a little with Klaus's feedback:

1. I too believe that the authinfo should be a required element.  This is useful for the losing registrar to verify prior to taking action.  
2. I find it interesting that this is the first example of an EPP protocol extension.  You might want to consider making this into a mapping where the object is keyrelay.  The create would create the keyrelay and the info response would be used in the poll message.  You can even generate a server unique identifier for the tracking of the keyrelay (was is dequeued and potentially to enable the losing registrar to mark it as accepted or rejected).  This might be over-engineering, but making it into an object with various commands (create, update, info, delete) to have the registry tracking the flow might be of use.
3. You might want to allow the gaining registrar to pass the key along with the associated set of DS records if the registry supports the DS Data Interface of RFC 5910.  In this case the losing registrar doesn't need to generate the DS and update the domain in the registry.  I wouldn't not recommend having the registry do any automatic DS updates, so the losing registrar would need to support setting the appropriate DS.  

JG

James F. Gould
Verisign

________________________________________
From: [email protected] [[email protected]] on behalf of Klaus Malorny [[email protected]]
Sent: Thursday, January 24, 2013 12:09 PM
To: [email protected]
Subject: Re: [provreg] Fwd: New Version Notification for        draft-gieben-epp-keyrelay-00.txt

On 24/01/13 17:44, Antoin Verschuren wrote:
> Op 24-01-13 14:13, Klaus Malorny schreef:
>>
>> I cannot agree. There are certain expectations with the protocol,
>> namely that the current registrar performs the necessary steps to
>> have the DNSKEYs published on the domain's name servers, and this
>> is already "process".
>
> Ah, I see how you look at it.
> If that's the case, then we should make DNSSEC mandatory, which it
> isn't. (though I would like it :-))
>
> Secure transfers are not mandatory as well.
> The only thing koch-dnsop-dnssec-operator-change describes is "if you
> want to do a secure transfer, this is how you can do it".
> We don't say you MUST do secure transfers because there is allways an
> alternative to go insecure and we cannot mandate DNSSEC.
>
> So if a key is relayed to a registrar, it is expected that he relays
> the key to the DNS operator that is appointed by the registant. The
> DNS operator can then publish the key to satisfy his customer, but we
> have no contractual control over the DNS operator nor any RFC to make
> that compulsory.
>
> I guess we could have an expiration timer on the key, but who should
> set that timer then ? Let's say a regular secure transfer can be done
> in 3 days, what is a reasonable timer? 1 week ? And should the gaining
> registrar set that timer ? And what if a gaining registrar sets the
> timer to 1 year? Should the registry prohibit that by local policy ?
> So suppose a registry does set a local policy of max 2 weeks for the
> timer.
> Then the timer can also be set by the losing registrar based on the
> local policy of the registry, and we don't have to communicate that
> timer over the protocol. It can be set in the cooperating DNS
> operator's provisioning system, or even be deleted by hand at will.
>
> The only thing a keyrelay command does is relay a key to facilitate a
> secure transfer process for those that want on both sides, but that is
> not mandatory to implement for every registrar or DNS operator.
>

Hi Antoin,

while it would be a bit too lax for me, if it is the desired design principle to
give no assurances about what the registrar does with the DNSKEY data in the
message, you also need not to give any assurances on the expiration timestamp I
suggested to be relayed along with the DNSKEYs. Let it simply be a hint to the
(potentially) losing registrar.

Regards,

Klaus







_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg