IETF Logo Mail Archive

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

Rubens Kuhl <rubensk@nic.br> Mon, 04 March 2019 12:47 UTC

Return-Path: <rubensk@nic.br>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD2C130FB8 for <regext@ietfa.amsl.com>; Mon, 4 Mar 2019 04:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp0yU-fSdLfE for <regext@ietfa.amsl.com>; Mon, 4 Mar 2019 04:47:31 -0800 (PST)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575D6130F32 for <regext@ietf.org>; Mon, 4 Mar 2019 04:47:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 4E12014BEBE; Mon, 4 Mar 2019 09:47:29 -0300 (-03)
X-Virus-Scanned: Debian amavisd-new at mail.nic.br
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAx9QkmtYA4n; Mon, 4 Mar 2019 09:47:26 -0300 (-03)
Received: from [IPv6:2804:431:9701:20ff:d8c4:ee83:c741:1278] (unknown [IPv6:2804:431:9701:20ff:d8c4:ee83:c741:1278]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id 5046614BEBD; Mon, 4 Mar 2019 09:47:26 -0300 (-03)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1551703646; bh=k0P/FNH/Nk7H7cDkRZfeJkaSRXumIYwHwIDPEoY87dw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=k4MPzafY3fzk+swnVU0yNKf0lgt/5MbzEe55ZsgIx9BCwjyqMAdf2i5672VMHgci3 T1K7uG4m8HrYyF7y10w38PEXIj5ZMBjKzXSbC6rYX2wLLNVSkXe9WDFEgx6xccDW6C O+YBjKOsNsjXn+waDVQitzmzAfe35GlpSzE8T4XY=
From: Rubens Kuhl <rubensk@nic.br>
Message-Id: <8C80C383-1EA7-484E-B0C8-F85089A16D6A@nic.br>
Content-Type: multipart/signed; boundary="Apple-Mail=_AC90B9C4-D1A3-4AA6-A8A8-573D4126209E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 04 Mar 2019 09:47:22 -0300
In-Reply-To: <alpine.DEB.2.20.1902261744450.19193@grey.csi.cam.ac.uk>
Cc: "regext@ietf.org" <regext@ietf.org>
To: Tony Finch <dot@dotat.at>
References: <19F54F2956911544A32543B8A9BDE0759FBF8765@NICS-EXCH2.sbg.nic.at> <8175501f-3365-c8d1-7a76-a4584e76734e@centralnic.com> <C4A68CA3-1ADE-4959-A51E-A73F4A4914DC@sidn.nl> <395DD26B-B2D1-4144-87BD-8DBCD772A8A5@lansing.dk> <34c35e4c575a4e338215b919c102cdfc@cira.ca> <2BE5D16A-F8A6-4609-9420-19BA1CE89185@nic.br> <alpine.DEB.2.20.1902261744450.19193@grey.csi.cam.ac.uk>
X-Mailer: Apple Mail (2.3445.102.3)
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 5046614BEBD
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/nPMBc_PrPhl7paY7Zb7iGKVAJcQ>
Subject: Re: [regext] Security Lock anyone? (Was: Preliminary agenda for Prague, and call for agenda items)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2019 12:47:34 -0000


> On 26 Feb 2019, at 14:46, Tony Finch <dot@dotat.at> wrote:
> 
> Rubens Kuhl <rubensk@nic.br> 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.

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

v2.23.0 | Report a Bug | By Email