Subject: Re: [regext] Security Lock anyone? (Was: Preliminary agenda for Prague, and call for agenda items)

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 4 Mar 2019 10:14:13 +0100

I've reserved room PARIS on wednesday, 2pm for that discussion. I hope
that everyone can make it - this is the "unstructured time" slot on
Wed afternoon, and so far it does not collide with any BoFs.. If
there's a more convenient time, please let me know in private mail...
i thought a doodle would be overkill for now..

best,
Alex

On Tue, Feb 26, 2019 at 6:46 PM Tony Finch <[email-masked]> wrote:
>
> Rubens Kuhl <[email-masked]> wrote:
> >
> > I imagine that DNS as a communication channel to assure registrant
> > willingness to change something, similar to CDNS/CDNSKEY, could be quite
> > useful. For instance, if the name servers that are delegated on the
> > registry are now pointing to new name servers, and this response is
> > signed by the current DS/DNSKEY on the delegation, changing the DNS
> > servers for that domain is pretty safe.
>
> There is RFC 7477 CSYNC, but I don't know of any implementations.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> safeguard the balance of nature and the environment
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 4 Mar 2019 04:32:14 -0500

Count me in.

Tim

---

From: Kal Feher <[email-masked]>
Date: Mon, 4 Mar 2019 23:30:03 +1100

I wont be on-site but will attend remotely if remote participation is
available.

On 4/3/19 8:32 pm, Tim Wicinski wrote:
>
> Count me in.
>
> Tim
>
>
> On Mon, Mar 4, 2019 at 4:14 AM Alexander Mayrhofer
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     On Tue, Feb 26, 2019 at 6:46 PM Tony Finch <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Rubens Kuhl <[email-masked] <mailto:[email-masked]>> wrote:
>     > >
>     > f.anthony.n.finch  <[email-masked] <mailto:[email-masked]>> 
>     http://dotat.at/
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Kal Feher
Melbourne, Australia

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 4 Mar 2019 09:47:22 -0300

> On 26 Feb 2019, at 14:46, Tony Finch <[email-masked]> wrote:
> 

It's possibly something in that direction, but CSYNC sounds a bit more complicated by requiring support of a new RR-type on the user-side. Using the same existing RRs would make it easier for end-user adoption.

I believe an OOB mechanism signalling the user intent of changing name server or in-bailwick glue records, with registry then fetching those records, would have more traction. The nature of that OOB would be policy-realm dependent; for some TLDs it could be as easy as flushing recursive DNS cache (https://developers.google.com/speed/public-dns/cache , https://www.verisign.com/en_US/security-services/public-dns/dns-cache/index.xhtml , https://cachecheck.opendns.com/), for some it might require a domain:update transaction from registrar.

In all cases, any name server change not coming from a synchronous EPP transaction should trigger a poll message informing the name servers have been changed and to which ones. This is likely something to regext to work on, possibly augmenting the existing draft-ietf-regext-change-poll- or using it as it is.

Security-wise, considering the limited adoption of DNSSEC, for non-signed delegation one alternative would be using only TCP queries to verify the new records.  This is far from perfect, but counters some threat vectors.

Rubens

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 4 Mar 2019 08:22:42 -0500

I nominate Alex to figure to make any remote technology work.

Win!

On Mon, Mar 4, 2019 at 7:30 AM Kal Feher <[email-masked]> wrote:

> regext mailing [email-masked]://www.ietf.org/mailman/listinfo/regext
>
> --
> Kal Feher
> Melbourne, Australia
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 4 Mar 2019 13:45:04 +0000

IP over https://en.wikipedia.org/wiki/Tin_can_telephone. For Science!

Von: regext <[email-masked]> Im Auftrag von Tim Wicinski
Gesendet: Montag, 4. März 2019 14:23
An: Kal Feher <[email-masked]>
Cc: [email-masked]
Betreff: Re: [regext] Security Lock anyone? (Was: Preliminary agenda for Prague, and call for agenda items)

Win!

On Mon, Mar 4, 2019 at 7:30 AM Kal Feher <[email-masked]<mailto:[email-masked]>> wrote:

I wont be on-site but will attend remotely if remote participation is available.
On 4/3/19 8:32 pm, Tim Wicinski wrote:

Count me in.

Tim

On Mon, Mar 4, 2019 at 4:14 AM Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>> wrote:

best,
Alex

On Tue, Feb 26, 2019 at 6:46 PM Tony Finch <[email-masked]<mailto:[email-masked]>> wrote:
>
> Rubens Kuhl <[email-masked]<mailto:[email-masked]>> wrote:
> >
> f.anthony.n.finch  <[email-masked]<mailto:[email-masked]>>  http://dotat.at/
> [email-masked]<mailto:[email-masked]>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

regext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf..org/mailman/listinfo/regext<https://www.ietf.org/mailman/listinfo/regext>

--

Kal Feher

Melbourne, Australia
_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: Kal Feher <[email-masked]>
Date: Fri, 8 Mar 2019 12:46:53 +1100

> In all cases, any name server change not coming from a synchronous EPP transaction should trigger a poll message informing the name servers have been changed and to which ones. This is likely somet…

I had previously read 7477 as being a useful tool for registrars, since
the 'parent agent' (section1.1) description seemed to fit them. That
would allow error handling to remain unchanged between EPP server and
client and no need to deploy registry logic to the csync ingestion tool.

The implications of adding or removing registry objects based only on
DNS signalling might be quite challenging to overcome in common manner.
The out of band error signalling imagined in RFC7477 would get much more
complex if CSYNC were deployed at the registry, but registrars
maintained the relationship with registrants.

> Security-wise, considering the limited adoption of DNSSEC, for non-signed delegation one alternative would be using only TCP queries to verify the new records.  This is far from perfect, but counte…
I know I'm probably being snobbish or dismissive, but I can't think of a
reasonable case where a domain name is import enough to a registrant to
server lock, but not important enough to deploy DNSSEC.
> Rubens
based on the users of the various server lock products I know,
delegation changes are rare enough and planned ahead enough to not
require bypassing the EPP update prohibitions without an explicit
unlock/re-lock sequence. DNSSEC keyrolls on the other hand seem like an
activity that should be able to continue and not require removal of
server lock states. So my ideal server lock product would be:

- supports CDS/CDNSKEY while locked

- server states applied OOB between RR and Ry

- server state change requests are standardised between Rt and RR, but
are not reliant on established Rt - RR systems, otherwise server lock is
no different to client lock in terms of risk.

-- 
Kal Feher
Melbourne, Australia

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 13 Mar 2019 10:17:51 -0400

On 25 Feb 2019, at 12:46, Tongfeng Zhang wrote:

> At .ca and all the TLDs CIRA operates,  we have a similar feature of 
> registry lock.
> We are interested in standardization for sure.
>
> There is a regiOps workshop coming up in May in Bangkok. I see a fit 
> there

Good idea. We have issued a call for proposals for the next ROW (see: 
http://regiops.net). Maybe we can have a panel of implementors with some 
Q&A. So if people are interested in describing their current solution at 
the ROW, please contact us ([email-masked]).

Marc.

> if regext is not the right place.
>
> Cheers,
> Tongfeng
>
>
> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Erwin Lansing
> Sent: Monday, February 25, 2019 11:25 AM
> To: [email-masked]
> Subject: Re: [regext] Security Lock anyone? (Was: Preliminary agenda 
> for Prague, and call for agenda items)
>
> Folks,
>
> At .dk we also offer a form form of registry lock, called VID, which 
> I’d like to redesign at some point.  Having a standardised, or at 
> least similar “enough” product offering across different 
> registries and TLDs would make it much more attractive for 
> registrants.  Even though I won’t be in Prague, I’m certainly 
> interested in following any standardisation effort.
>
> Best,
> Erwin
>
>
>
>> On 25 Feb 2019, at 17.11, Marc Groeneweg <[email-masked]> 
>> wrote:
>>
>> All,
>>
>> At SIDN (for .nl) we have our own form of registry lock called .nl 
>> control (https://www.sidn.nl/en/nl-control?language_id=2). Perhaps 
>> this can be used as input for a joined effort in increasing security 
>> around registry/registrar operations.
>>
>> Regards,
>> Marc Groeneweg
>>
>> On 25/02/2019, 14:57, "regext on behalf of Gavin Brown" 
>> <[email-masked] on behalf of [email-masked]> 
>> wrote:
>>
>>    If a BoF happens in Prague I will certainly attend.
>>
>>    On 25/02/2019 07:26, Alexander Mayrhofer wrote:
>>> Antoin, all,
>>>
>>>
>>>
>>> for now this is more a question / request to the group, rather than 
>>> a
>>> specific agenda slot request – but:
>>>
>>>
>>>
>>> In the light of the recent attacks on registration interfaces, do we
>>> want to take a fresh look at standardization of “Registry Lock” 
>>> /
>>> “Security Lock”. There’s some previous work on this topic (see
>>> https://tools.ietf.org/html/draft-wallstrom-epp-registrant-problem-statement-00).
>>> As Patrick pointed out, there’s also some IPR considerations in 
>>> this
>>> area (See his blog post at
>>> http://www.circleid.com/posts/20150603_registry_lock_or_epp_with_two_factor_authentication/).
>>>
>>>
>>>
>>> I constantly hear from registrars that “Security Lock” (our 
>>> product
>>> name) would be much more attractive if there wasn’t a myriad of
>>> different processes at each registry – so my take is that 
>>> there’s
>>> room for standardization (which probably goes beyond the pure EPP 
>>> extension).
>>> I’m also hearing some fellow ccTLD colleages are interesting in a
>>> common “profile”.
>>>
>>> Would regext be the right spot for such a discussion? If yes, would
>>> it be interesting to hold a 20 minutes slot in Prague? Or even a
>>> Bar-BoF before we “report back” to the working group?
>>>
>>>
>>>
>>> Best,
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>> *Von:*regext <[email-masked]> *Im Auftrag von *Antoin
>>> Verschuren
>>> *Gesendet:* Sonntag, 24. Februar 2019 14:43
>>> *An:* Registration Protocols Extensions <[email-masked]>
>>> *Betreff:* [regext] Preliminary agenda for Prague, and call for
>>> agenda items
>>>
>>>
>>>
>>> Hi all,
>>>
>>> Please find the preliminary agenda for Prague attached.
>>> I hope I captured everyone that has requested time to speak. If not,
>>> let the chairs know.
>>> We still have a little bit of time left on the agenda, so if you 
>>> have
>>> urgent agenda items, let us know as well.
>>> If you are on the agenda, start preparing ;-)
>>>
>>>
>>>
>>>
>>> Regards, Jim and Antoin
>>>
>>> - --
>>> Antoin Verschuren
>>>
>>> Tweevoren 6, 5672 SB Nuenen, NL
>>> M: +31 6 37682392
>>>
>>>
>>>
>>>
>>>
>>    Gavin Brown
>>    Chief Technology Officer
>>    CentralNic Group plc (LSE:CNIC)
>>    Innovative, Reliable and Flexible Registry Services
>>    for ccTLD, gTLD and private domain name registries
>>    https://www.centralnic.com/
>>    +44.7548243029
>>
>>    CentralNic Group plc is a company registered in England and Wales 
>> with
>>    company number 8576358. Registered Offices: 35-39 Moorgate, 
>> London,
>>    EC2R 6AR.
>>
>>