Subject: [provreg] Registry lock - setting statuses on hosts

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Thu, 3 Oct 2013 15:13:52 +0000

Hello,

At CIRA we are working through our approach to Registry Lock and are wondering what perspectives there are out there on the approach to setting of server statuses on hosts - i.e. the locking of hosts.

We are considering two main approaches:

1.       From the setting of a "domain lock" (serverUpdate, serverTransfer and serverDelete prohibited statuses set), automatically cascade the related host statuses (serverUpdate and serverDelete prohibited) to all host entities assigned (nameservers) to the domain in question.

2.       Separate the locking of domains and hosts into disparate transactions - i.e. one domain update transaction to set the domain server statuses followed by subsequent host update transactions to set server statuses on desired hosts.

Our main considerations here are balancing ease of use from a registrar's perspective vs differing too far from a consistent industry approach.

All feedback would be appreciated.

Thanks,
Stu

Stu Olmstead-Wilcox, Development Manager
Canadian Internet Registration Authority (CIRA)
Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYSTEMS<http://twitter.com/CIRANEWS>
Trends, Commentary, Perspective.  Stay tuned to cirablog.ca<http://www.cirablog.ca/>

---

From: Jan Saell <[email-masked]>
Date: Sun, 06 Oct 2013 18:10:05 +0200

Hello all.

- From my point of view the Server flags is never ever something that the
registrar should be able to set over EPP. This (in my opinion) is
something that the registry only can set, and perhaps the registrar och
registrant with some other, out of bound, method.

But if we put that aside, i think one have to separate the domain lock
from the host lock.

Think of the possibility that you have one domain having hosts (name
servers) from another domain. IN that case, you might want to lock the
domain without host and also unlock a has separate to update it.

This is my 5 cents.

Mvh jan

On 10/03/2013 05:13 PM, Stuart Olmstead-Wilcox wrote:
> Hello,
> 
>  
> 
> At CIRA we are working through our approach to Registry Lock and are
> wondering what perspectives there are out there on the approach to
> setting of server statuses on hosts – i.e. the locking of hosts.
> 
>  
> 
> 1.       From the setting of a “domain lock” (serverUpdate,
> serverTransfer and serverDelete prohibited statuses set), automatically
> cascade the related host statuses (serverUpdate and serverDelete
> prohibited) to all host entities assigned (nameservers) to the domain in
> question.
> 
>  
> 
> 2.       Separate the locking of domains and hosts into disparate
> transactions – i.e. one domain update transaction to set the domain
> server statuses followed by subsequent host update transactions to set
> server statuses on desired hosts.
> 
>  
> 
> Our main considerations here are balancing ease of use from a
> registrar’s perspective vs differing too far from a consistent industry
> approach. 
> 
>  
> 
> *Stu Olmstead-Wilcox, *Development Manager
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
> 

- -- 
+-------------------------------------------------------------------
! Irial / YASK AB
! Att: Jan Saell
! Box 59, S-692 21 KUMLA, SWEDEN
! Tel: 019-58 25 15     Int +46-19 58 25 15     Fax +46-19 58 38 05
! E-mail: [email-masked]
! PGP Fingerprint: E957 23C8 9F51 0958 B9AD  7F18 404A 5DA1 F944 A08B

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 7 Oct 2013 15:56:24 +0200

On 3 okt 2013, at 17:13, Stuart Olmstead-Wilcox <[email-masked]> wrote:

> At CIRA we are working through our approach to Registry Lock and are wondering what perspectives there are out there on the approach to setting of server statuses on hosts – i.e. the locking of hosts.
>  
> 1.       From the setting of a “domain lock” (serverUpdate, serverTransfer and serverDelete prohibited statuses set), automatically cascade the related host statuses (serverUpdate and serverDelete prohibited) to all host entities assigned (nameservers) to the domain in question.
>  
> 2.       Separate the locking of domains and hosts into disparate transactions – i.e. one domain update transaction to set the domain server statuses followed by subsequent host update transactions to set server statuses on desired hosts.
>  
> Our main considerations here are balancing ease of use from a registrar’s perspective vs differing too far from a consistent industry approach. 

Do we actually know exactly what changes are no longer allowed when there is a registry lock?

For example, what about DNSSEC material?

   Patrik

---

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Thu, 10 Oct 2013 01:41:10 +0000

Jan,

We are in agreement on both counts.  

> From my point of view the Server flags is never ever something that the registrar should be able to set over EPP. This (in my opinion) is something that  
> the registry only can set, and perhaps the registrar och registrant with some other, out of bound, method

At least for our initial implementation we will not be allowing locking via epp.

 > But if we put that aside, i think one have to separate the domain lock from the host lock.

Fundamentally agree.

The only consideration here is ease of use for rant / rar if we cascade server statuses to all hosts assigned to a domain ... a "super" lock for lack of a better term.  I'm concerned about rant's who think their domain is locked, but it is actually still potentially vulnerable because the host(s) are not locked.

Stu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jan Saell
Sent: October-06-13 12:10 PM
To: [email-masked]
Subject: Re: [provreg] Registry lock - setting statuses on hosts

Hello all.

- From my point of view the Server flags is never ever something that the registrar should be able to set over EPP. This (in my opinion) is something that the registry only can set, and perhaps the registrar och registrant with some other, out of bound, method.

But if we put that aside, i think one have to separate the domain lock from the host lock.

Think of the possibility that you have one domain having hosts (name
servers) from another domain. IN that case, you might want to lock the domain without host and also unlock a has separate to update it.

This is my 5 cents.

Mvh jan

On 10/03/2013 05:13 PM, Stuart Olmstead-Wilcox wrote:
> serverTransfer and serverDelete prohibited statuses set), 
> automatically cascade the related host statuses (serverUpdate and 
> serverDelete
> prohibited) to all host entities assigned (nameservers) to the domain 
> in question.
> 
>  
> 
> registrar’s perspective vs differing too far from a consistent 
> industry approach.
> 
>  
> 
> *Stu Olmstead-Wilcox, *Development Manager Canadian Internet 
> Registration Authority (CIRA)
> Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYSTEMS 
> <http://twitter.com/CIRANEWS> Trends, Commentary, Perspective.  Stay 
> tuned to cirablog.ca <http://www.cirablog.ca/>
> 
>  
> 
> 
> 

- --

---

From: Rubens Kuhl <[email-masked]>
Date: Wed, 9 Oct 2013 22:44:28 -0300

> The only consideration here is ease of use for rant / rar if we cascade server statuses to all hosts assigned to a domain ... a "super" lock for lack of a better term.  I'm concerned about rant's w…

One option would be to require registry lock to only be offered to
1) Domains with in-bailwick nameservers 
2) Domains with nameservers from domains that are also subject to registry lock

Rubens

---

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Thu, 10 Oct 2013 01:45:27 +0000

> For example, what about DNSSEC material?

Our initial approach will be to adhere strictly to the serverUpdateProhibited definition.  If set via lock, then no domain updates will be permitted - including DNSSEC material.  

If this begins to pose a problem in the future (we will be fully epp DNSSEC compliant 1st quarter 2014) we will revisit.

Stu

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: October-07-13 9:56 AM
To: Stuart Olmstead-Wilcox
Cc: [email-masked]
Subject: Re: [provreg] Registry lock - setting statuses on hosts

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Oct 2013 04:27:37 +0200

> If this begins to pose a problem in the future (we will be fully epp DNSSEC compliant 1st quarter 2014) we will revisit.

Thanks!

How do other registries handle registry lock and for example DNSSEC material updates?

I.e. it seems to be that a registry lock make key rollover of the KSK for the zone be impossible.

   Patrik

---

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Thu, 10 Oct 2013 12:43:12 +0000

> I.e. it seems to be that a registry lock make key rollover of the KSK for the zone be impossible.

It certainly does seem that it would make that process cumbersome.  Interested in other registry feedback here as well.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: October-09-13 10:28 PM
To: Stuart Olmstead-Wilcox
Cc: [email-masked]
Subject: Re: [provreg] Registry lock - setting statuses on hosts

Thanks!

   Patrik

---

From: Mark Elkins <[email-masked]>
Date: Tue, 15 Oct 2013 12:49:15 +0200

I'd like to follow up this question with a similar question....

Should anything be allowed to block an EPP based DNSSEC update?

ie any type of registry/domain/host whatever lock... only exception
being ServerHold - which to me is the Registrar has been locked out of
the Registry System...

I believe it is "No" - in order to keep DNSSEC updates as simple as
possible. (KISS).  Even if the Nameservers (and associated) records of a
domain are no longer being published (In a Delete/Redemption or
ClientHold) - I think the Registry should still not hinder a DNSSEC
Update/Key Rollover.
This could stop a Key-Rollover completing if the DNS Provider can not
see "DS's" - because Records are not being published - but that is a
different problem.

What do registries say/do?

-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       [email-masked]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

---

From: Jan Saell <[email-masked]>
Date: Tue, 15 Oct 2013 15:25:21 +0200

Well an update is and update.

And if we are talking about registry lock (in whatever form you do it) i
think that its a form of lock for any changes. And to do the unlock (and
lock), you need some sort of out of band method from EPP to protect the
domain.

And if you would allow a DNSSEC update regardless of lock status, then
this would be a prime target for disabling a domain (Inserting false
DNSSEC records and remove old ones would disable the domain).

This means that to do a key rollover you have to plan ahead, thats true
and it also means that the administration is harder but thats kind of
the point to the lockdown isn't it.

Best regards
jan

- --

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 15 Oct 2013 15:39:55 +0200

op 15-10-13 12:49, Mark Elkins schreef:

> I believe it is "No" - in order to keep DNSSEC updates as simple
> as possible. (KISS).  Even if the Nameservers (and associated)
> records of a domain are no longer being published (In a
> Delete/Redemption or ClientHold) - I think the Registry should
> still not hinder a DNSSEC Update/Key Rollover. This could stop a
> Key-Rollover completing if the DNS Provider can not see "DS's" -
> because Records are not being published - but that is a different
> problem.
> 

There is a scenario where you hijack the registrar, and change the
DNSSEC key material at the registry to DOS the victim. Or delete the
DNSSEC key material so you can do cache pollution.

So I think the registrant should be able to state what should be locked:
- -Administrative parameters to prevent legal registrant/registrar changes
- -NS and in bailiwick glue records to prevent delegation redirection
- -DNSSEC key material changes to adjust security levels

If you do the latter, you should unlock before you do a key rollover,
but that is your own child policy decision.
I would personally do so as my child policy is to only do a well
prepared key rollover every X years.

In stead of a very strict administrative (un)lock procedure, I would
also favor a mechanism where a registrant needs to approve every
change at the registry by supplying a credential that the registry and
registrant both know. A request could be approved by the registrants
pgp signature for example, where the public key is registered at the
registry when the domain is registered. But that would need to be
supported over the complete chain, and needs standardization.

- -- 
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-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 16 Oct 2013 07:32:44 +0200

Having the private key at the domain holder would actually prevent that.

	jaap

---

From: Marc Groeneweg <[email-masked]>
Date: Wed, 16 Oct 2013 07:59:22 +0000

>Having the private key at the domain holder would actually prevent that.

Is that true Jaap? I don't think so. The villain makes his own private key, and makes
sure he gets a real secure delegation to his own infrastructure, hijacking the domain
name and still have DNSSEC validation in place. I guess it's all about timing isn't it?

Regards,
Marc