Re: Registry lock - two-factor or intervention

Jay Daley <[email protected]> Thu, 19 Sep 2013 11:29:30 +1200
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
Hi Francisco

On 19/09/2013, at 10:41 AM, Francisco Obispo <[email protected]> wrote:

> Hi Jay,
> 
> Let me give you another example,
> 
> A registrar mistakenly changes a record (even authorizes a change), without its client knowing about it, the domain name goes offline, or even worse, gets hijacked. 

How exactly do you think a registrar can mistakenly authorise a change via an OOB mechanism?  



In my view, the threats and  realistic likelihood of those threats, are:

1.  The registrar is hacked and the miscreant sends a change request using the registrar credentials. [Likelihood = Possible]

2.  The registrar mistakenly requests a change. [Likelihood = Unlikely]

3.  The registrar mistakenly requests a change and then also mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

I would also suggest that the likelihood of 3 is exactly the same as the two following:

4.  The registrar mistakenly requests a change and then the *registrant* mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

5.  The *registrant* mistakenly requests a change and then also mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

> 
> My idea of a registry lock is to have a direct relationship with the registrant/name holder, so it can decide wether the domain name is allowed to be changed by the registrar.

The implications of that are significant.  Both for the registry and registrar.  Those implications include:

- how does the registry authenticate the registrant (compare delivering one secure token to each registrar with delivering one to each registrant)?
- the risk that the registry will use the relationship for something they shouldn't 
- potentially (depending on how it is set up) the need for the registry to have a customer support team and what happens if the registrant gets poor customer service from the registry?


I would be very careful at rushing into the idea that the registry must have a direct relationship with the registrar if I were you.  Doing it via the registrar is the path of least resistance and less risk.


> Verisign offers a registry lock, so perhaps they can share a little bit on how they do it, and how they authenticate the request in cases where contact privacy is enabled.

There are a number of registries that do it who are part of CENTR and gave presentations on it recently:

.dk
	• registrants have direct contact with registry
	• VID Service (Very Important Domain) - only 1000 VID out  of 1.2 million active domains
	• uses a snail mail approach to enact changes.  very robust, but slow which dies frustrate some people
	• charge 50 krona per annumn (5 pds Sterling)
.cz
	• registrant asks registry for change. Can lock two things
		• just transfer
		• lock all changes
	• done via letter which can be downloaded from website
	• offered as a free service
	• have about 5,000 out of 1 million
	• registrars have all locked their own domains
.nl
	• service called .nl control
	• lock all data, but not name servers
	• it is a manual process
	• sold for 50 Euros per annum
	• numbers sold are very low

Jay

> 
> 
> 
> On Sep 18, 2013, at 4:56 PM, Jay Daley <[email protected]> wrote:
> 
>> We came to the conclusion that a manual verification (or possibly another out-of-band verification) does not need to be to the registrant but works perfectly well to the registrar.  That of course is much better for those of us that need to maintain the registry->registrar->registrant model and not introduce a registry->registrant component.
> 
> Francisco Obispo 
> email: [email protected]
> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
> PGP KeyID = B38DB1BE
> 
> 
> 
> 


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

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