IETF Logo Mail Archive

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

Tony Finch <dot@dotat.at> Mon, 25 February 2019 12:17 UTC

Return-Path: <dot@dotat.at>
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 8B00C130E64 for <regext@ietfa.amsl.com>; Mon, 25 Feb 2019 04:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ouG33hLg3j-G for <regext@ietfa.amsl.com>; Mon, 25 Feb 2019 04:17:35 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 912D112D4E6 for <regext@ietf.org>; Mon, 25 Feb 2019 04:17:35 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39214) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gyFCK-000FGb-id (Exim 4.91) (return-path <dot@dotat.at>); Mon, 25 Feb 2019 12:17:28 +0000
Date: Mon, 25 Feb 2019 12:17:28 +0000
From: Tony Finch <dot@dotat.at>
To: Bill Woodcock <woody@pch.net>
cc: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, Antoin Verschuren <ietf@antoin.nl>, Registration Protocols Extensions <regext@ietf.org>
In-Reply-To: <563E062B-10D1-40F9-B5A0-9ADB8B21C50C@pch.net>
Message-ID: <alpine.DEB.2.20.1902251211520.19193@grey.csi.cam.ac.uk>
References: <19F54F2956911544A32543B8A9BDE0759FBF8765@NICS-EXCH2.sbg.nic.at> <563E062B-10D1-40F9-B5A0-9ADB8B21C50C@pch.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-1262806468-1551097048=:19193"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/_PeUBOpnnHSYJk9LI13E76fqnU4>
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, 25 Feb 2019 12:17:38 -0000

Bill Woodcock <woody@pch.net> wrote:

> We’d be _very interested_ in seeing a standardized, end-to-end
> registry-locking model. Specifically, one in which the registrant signs
> change requests, and the registry validates the signatures, and nobody
> in the registrar path is involved in any way.

How do you see this interacting with DNSSEC key rollovers?

I would like to see better automation for KSK rollovers, but the poor
state of registrar APIs and the added risk of exposing registrar
credentials makes it more difficult than I would like. I guess the best
answer is more RFC 7344 CDS/CDNSKEY support, because that avoids the
shared secret risks and it won't be made more difficult by security
hardening the delegation update process.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5. Rough or very
rough, but slight or moderate in Irish Sea. Mainly fair. Good, occasionally
poor.

v2.23.0 | Report a Bug | By Email