[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Peter Thomassen <peter@desec.io> Mon, 20 May 2024 14:28 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 3683BC14F5E5; Mon, 20 May 2024 07:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTgX0KX37eTu; Mon, 20 May 2024 07:28:43 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E35C14E515; Mon, 20 May 2024 07:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Cc:To:From:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: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=bbpveDZTPByVNRGo0aaYTGE+s0iUVuSmtQb05Qi0U2Y=; b=pefFS0zApkSABXoYw5J6THfCM7 JYi78D79TPAeohLuVYsnnjbCkYLU8sEzEjljhRArrFzcHgtxuEwIlABXKe/z+qr4h5dgrMhWi9F3w detwYn7gpbH6gX9I2mEowoOgldmE6P3lCgL2Lg1CDHQijVevTef3Y/lwbgjoMiIloMRzyvMn4WKr8 VeIcyRjmozQ3psNCgordC8lcu2C7CbrQ0O6HZiRSerNdS1rLIjwhDdbN6OpZmPbgZLgJ+gq66ARNV fsTPzhpTTofFYBjE4vfFzPaP3Bmv+brCZKMou+UN2HfNOqZmrp6N/28hNUNVA3Vi8ce5ULw7r1drL OUWn3w4g==;
Received: from [2a00:20:4044:b300:d8d6:99e9:57af:d17e] by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1s940E-00HDH8-80; Mon, 20 May 2024 16:28:38 +0200
Message-ID: <10fa7757-c4f0-4508-be3c-a54f5f353bf2@desec.io>
Date: Mon, 20 May 2024 16:28:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Peter Thomassen <peter@desec.io>
To: Paul Wouters <paul@nohats.ca>
References: <171570741645.58676.5533506627285888134@ietfa.amsl.com> <b984d68a-f565-4178-b575-9fe2261a16a6@desec.io> <81868047-2b70-82d6-760b-7cb1cc898ff6@nohats.ca> <df0d36b9-596c-4419-8e03-0ba04465d896@desec.io> <1b099313-2266-70c7-837b-9732f2ea9bfb@nohats.ca> <28608b75-69f1-4b3d-81f9-67375921c86b@desec.io>
Content-Language: en-US
In-Reply-To: <28608b75-69f1-4b3d-81f9-67375921c86b@desec.io>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: QPMFKRG5BSI3WXBQBRVXWZAJBHOOOPBW
X-Message-ID-Hash: QPMFKRG5BSI3WXBQBRVXWZAJBHOOOPBW
X-MailFrom: peter@desec.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Wouters <paul.wouters@aiven.io>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-dnssec-bootstrapping@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UKKNfDrvhN19lLVhyXcOhcYJqU4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Paul,

We addressed the last open issue (see below) and submitted a new revision (-10).

Thanks for the helpful discussion, I feel it's made the draft better!

On 5/18/24 03:23, Peter Thomassen wrote:
>>> OLD
>>>    CDS/CDNSKEY records and corresponding signaling records MUST NOT be
>>>    published without the zone owner's consent.  Likewise, the child DNS
>>>    operator MUST enable the zone owner to signal the desire to turn off
>>>    DNSSEC by publication of the special-value CDS/CDNSKEY RRset
>>>    specified in [RFC8078] Section 4.  To facilitate transitions between
>>>    DNS operators, child DNS operators SHOULD support the multi-signer
>>>    protocols described in [RFC8901].
>>>
>>> NEW
>>>    It is possible to add CDS/CDNSKEY records and corresponding signaling
>>>    records to a zone without explicit knowledge of the domain owner.  To
>>>    spare domain owners from being caught off guard by state changes
>>>    induced by this practice, Child DNS operators doing so are advised to
>>>    make this transparent.
>>
>> Maybe add:   ", for example by notifying the domain owner via email".
> 
> Mmh, I find this quite prescriptive ("a priming example"). It could also be done as an info box when you create the zone (perhaps you can untick a box to disable), or as an advertised feature when you book the plan. Those approaches seem favorable, because they are ahead of time (before it actually happens), while a notification is after the fact.
> 
> Now, I'm not sure whether we should go into elaborating on all of this; but *if* we say something, I feel we should mention one of the "ahead-of-time" ways. I'd be curious to know what you think of this.

NEW
    It is possible to add CDS/CDNSKEY records and corresponding signaling
    records to a zone without the domain owner's explicit knowledge.  To
    spare domain owners from being caught off guard by the ensuing DS
    changes, child DNS operators following this practice are advised to
    make that transparent, such as by informing the domain owner during
    zone creation (e.g., in a GUI), or by notifying them via email.

Thanks,
Peter

-- 
https://desec.io/