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

[Kal Feher <[e-mail]>]

On 4/3/19 11:47 pm, Rubens Kuhl wrote:
>
>> On 26 Feb 2019, at 14:46, Tony Finch <[e-mail]> wrote:
>>
>> Rubens Kuhl <[e-mail]> 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.
>
> 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.

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 counters some threat vectors.
>
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.


>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Kal Feher
Melbourne, Australia