[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt

Peter Thomassen <peter@desec.io> Wed, 30 June 2021 01:04 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E103A1014 for <dnsop@ietfa.amsl.com>; Tue, 29 Jun 2021 18:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 PzNaURxcB1aP for <dnsop@ietfa.amsl.com>; Tue, 29 Jun 2021 18:04:34 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 5C59B3A1013 for <dnsop@ietf.org>; Tue, 29 Jun 2021 18:04:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:To:References:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OXRb7UrYjTkxnMSjCDdS3mF2hHc6eY34oYhdPO+8r+8=; b=SFX/XjdgZahJbhRPI07k09hhuu VxJYXJYfJhVQ0skCG8cpKtBtUbWF5V8TiS3CbjLVO7Aqampo0c1UAtjBgVEgYJ998j0HMLVCwU6pN Mus84PgI4P5tJneChkzX0nECJEoZSXhI4DQRhwVwjE180etMbP0VieokbA3pb5ujqIj03h8S5hO0P 9mN+435F+CuAu0Y6df3EHeWawnaGFYk0ueHxj2eL7mgJZ/KaXIogzBJDGjm9tmV6pded6ZXIjw7AQ dVNvuDL0SjO0e/dpc8C6zuUnRXC9FsYoF4us26cdT4NntXmFYGjYsJpik9YmFema0a6qkc4nMc5GS qcgW88fw==;
Received: from [2a02:8109:92c0:2318::5b5b] by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1lyOeV-0001ur-LV for dnsop@ietf.org; Wed, 30 Jun 2021 03:04:31 +0200
References: <162501401344.11900.6337869126187518924@ietfa.amsl.com>
To: dnsop@ietf.org
From: Peter Thomassen <peter@desec.io>
X-Forwarded-Message-Id: <162501401344.11900.6337869126187518924@ietfa.amsl.com>
Message-ID: <c1c73016-7476-3048-e271-e83efb6fcc72@desec.io>
Date: Wed, 30 Jun 2021 03:04:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <162501401344.11900.6337869126187518924@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yFZMZLwziBf5C1KfM0i1roXfRhQ1l7Wcp"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s8QnyT2m-7zUbFaZFlVDMjPuE3A>
Subject: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2021 01:04:40 -0000

Hi all,

As far as I'm concerned, the pain in maintaining a secure delegation is often too high, and way too many DNS delegations are still insecure. I presume that many of you agree, which (supposedly) is why mechanisms like RFC 8078 have been created. And indeed, RFC 8078 is great for rollovers.

Unfortunately, current methods for bootstrapping a secure delegation are manual/slow/out-of-band/error-prone (registrar's web interface) or slow/unauthenciated (monitor CDS/CDNSKEY for a few days via TCP and hope for the best). As an operator that's trying to push DNSSEC, I wish this situation could be improved.

With the below draft, I am proposing how I think the problem could be solved in-band, authenticated and immediate. I've asked some registries, and they see value in it. While I know that the WG currently does not adopt any documents, I still would like to share it, and possibly have a discussion about it. Is there any interest in this?

Thanks,
Peter


-------- Forwarded Message --------
Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
Date: Tue, 29 Jun 2021 17:46:53 -0700
From: internet-drafts@ietf.org
To: Peter Thomassen <peter@desec.io>


A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:		draft-thomassen-dnsop-dnssec-bootstrapping
Revision:	00
Title:		DNSSEC Bootstrapping
Document date:	2021-06-30
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:           https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping


Abstract:
    This document describes an authenticated in-band method for automatic
    signaling of a DNS zone's delegation signer information from the
    zone's DNS operator.  The zone's registrar or registry may
    subsequently use this signal for automatic DS record provisioning in
    the parent zone.

                                                                                   


The IETF Secretariat