Re: [ietf-smtp] [OT] (signed TLDs)

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 16 October 2019 03:20 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7E12084C for <ietf-smtp@ietfa.amsl.com>; Tue, 15 Oct 2019 20:20:40 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MlXG8aPm9IPE for <ietf-smtp@ietfa.amsl.com>; Tue, 15 Oct 2019 20:20:37 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881A4120849 for <ietf-smtp@ietf.org>; Tue, 15 Oct 2019 20:20:37 -0700 (PDT)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 59FFC2BBB59 for <ietf-smtp@ietf.org>; Tue, 15 Oct 2019 23:20:36 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <1C0209DF-A3FF-4FA2-991C-560EB418CD0E@isc.org>
Date: Tue, 15 Oct 2019 23:20:34 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <1E4FADBE-5B95-41C0-B401-607D6A8FF2FA@dukhovni.org>
References: <20191011160802.50C81C9B780@ary.qy> <alpine.DEB.2.20.1910141200120.8949@grey.csi.cam.ac.uk> <alpine.OSX.2.21.99999.368.1910141020460.72467@ary.local> <alpine.DEB.2.20.1910151228410.8949@grey.csi.cam.ac.uk> <5DA5F942.5030307@isdg.net> <4667cc53-63cd-4cd1-97a5-80a4f7f28fad@gulbrandsen.priv.no> <1C0209DF-A3FF-4FA2-991C-560EB418CD0E@isc.org>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/lj6CqX9xFqvyuPqtVTUI8BARhUo>
Subject: Re: [ietf-smtp] [OT] (signed TLDs)
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 03:20:40 -0000

> On Oct 15, 2019, at 10:36 PM, Mark Andrews <marka@isc.org> wrote:
> 
> Well when the delegation was initially registered credential where exchanged
> even if that was a user name / password pair.  This allowed NS records and
> glue address records to be updated securely.  Updating/adding DS records is no
> different.  You use the existing mechanisms, initially this was talking to the
> registry directly.  These days it is intermediated through a registrar.

Yes, but as you're well aware, with DNSSEC users need a standard
interface that enables automation of KSK/DS updates, and the extra
hop through the registrar is rather a major obstacle.  Also,
in many cases the DNS zone operator needs to be empowered to
do key management, without necessarily having full control of
the zone for transfers, ...

Perhaps it should be possible for the user to obtain from a token
that authorizes a key pair for direct access to the registry for
(purposes of DS RR updates) by the holder of the keypair.  The
token (and associated key) might then be delegated to the DNS
operator.

That token is presently a signed CDS/CDS0 record, which handles
everything but initial enrollment (bootstrapping), for which
.CZ, .CH, et. al. are exploring ToFU approaches.

-- 
	Viktor.