Re: [dd] [Ext] Challenges with DELEG awareness in DNSKEY
Edward Lewis <edward.lewis@icann.org> Wed, 20 March 2024 14:17 UTC
Return-Path: <edward.lewis@icann.org>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492B0C15199B; Wed, 20 Mar 2024 07:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 Q6qx0iVzKIcw; Wed, 20 Mar 2024 07:17:36 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 152CFC169506; Wed, 20 Mar 2024 07:17:36 -0700 (PDT)
Received: from MBX112-W2-VA-1.pexch112.icann.org (out.mail.icann.org [64.78.48.207]) by ppa4.dc.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 42KEHAuE000748 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Mar 2024 07:17:10 -0700
Received: from MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) by MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Wed, 20 Mar 2024 10:17:34 -0400
Received: from MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) by MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) with mapi id 15.02.1258.028; Wed, 20 Mar 2024 10:17:34 -0400
From: Edward Lewis <edward.lewis@icann.org>
To: Bob Halley <bhalley=40cloudflare.com@dmarc.ietf.org>, "dd@ietf.org" <dd@ietf.org>
Thread-Topic: [Ext] [dd] Challenges with DELEG awareness in DNSKEY
Thread-Index: AQHaes2Wx0mdnKwWNk+vDxllcsU+1bFArReA
Date: Wed, 20 Mar 2024 14:17:34 +0000
Message-ID: <D0C2993F-4912-4059-B5D4-550C1C002E50@icann.org>
References: <CAB1+oZ5vkivgegiL7CaAN9GKpymqgMiC+VpXr_1X--ohVcd4cQ@mail.gmail.com>
In-Reply-To: <CAB1+oZ5vkivgegiL7CaAN9GKpymqgMiC+VpXr_1X--ohVcd4cQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
x-originating-ip: [192.0.47.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C5F6BF23D8589240BF3D8415FF314FD1@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-20_09,2024-03-18_03,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/gQEH6H_GMdowtdM2Uk3DS-72Z3s>
Subject: Re: [dd] [Ext] Challenges with DELEG awareness in DNSKEY
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 14:17:42 -0000
One point I want to echo: On 3/20/24, 09:50, "dd on behalf of Bob Halley" <dd-bounces@ietf.org on behalf of bhalley=40cloudflare.com@dmarc.ietf.org> wrote: >Do not use an awareness flag in the DNSKEY RRset. One of the lessons from Automatic Updates of DNSSEC Trust Anchors (RFC 5011) is that overloading the DNSKEY RR set is troublesome. Convenient in some sense, but ultimately troublesome. The DNSKEY RR set is vital to DNSSEC operations, it's part of every validation done. The set must be carefully designed to work just right. If we lay other missions on it, it gets fragile. E.g, response size concerns when trying to roll the DNS Security Algorithm of a zone while relying on Automatic Updates to convey the new trust anchor and revoke the old. Adding the proposed new trust anchor key there seems sensible, and the deadweight isn't a problem until fragmentation is considered.
- [dd] Challenges with DELEG awareness in DNSKEY Bob Halley
- Re: [dd] [Ext] Challenges with DELEG awareness in… Edward Lewis
- Re: [dd] Challenges with DELEG awareness in DNSKEY Roy Arends
- Re: [dd] Challenges with DELEG awareness in DNSKEY Petr Špaček