[DNSOP] Updates to draft-huque-dnsop-multi-alg-rules

Christian Elmerot <christian@elmerot.se> Mon, 02 June 2025 12:17 UTC

Return-Path: <christian@elmerot.se>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 44E172FA56E6 for <dnsop@mail2.ietf.org>; Mon, 2 Jun 2025 05:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=elmerot.se
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i60i28iVL709 for <dnsop@mail2.ietf.org>; Mon, 2 Jun 2025 05:17:39 -0700 (PDT)
Received: from mail.elmerot.se (limbo.elmerot.se [82.196.12.116]) by mail2.ietf.org (Postfix) with ESMTP id BFAEB2FA56E1 for <dnsop@ietf.org>; Mon, 2 Jun 2025 05:17:39 -0700 (PDT)
Received: from [IPV6:2606:4700:110:88a8:ae60:37cc:ba78:4cec] (unknown [IPv6:2a09:bac1:64e0:8::c9:9]) by mail.elmerot.se (Postfix) with ESMTPSA id B46C09048 for <dnsop@ietf.org>; Mon, 02 Jun 2025 12:12:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.elmerot.se B46C09048
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elmerot.se; s=mail; t=1748866366; bh=hASxK7lS6KaeOWWpBlnCwFlhqCj/Kbmk889+/NRqyUA=; h=Date:To:From:Subject; b=PyQMDXMvQO6lPYlF2YEaJijDmCRBch6IgIFBK9cvsxle4Y0aWPkU38UlVq3Pvddd+ IqzdFcwB16BPvqhpYxc4gqv+sZmSjgOo5L10gXM6OB9OmfosUOSCDU08tw/jpXfhZy 1f/PKtvsWjMAL+r8AXKzsvzCDwzf5YJgaHDmQB5A=
Message-ID: <9260289a-602e-455f-bcd5-af281b4d2c3d@elmerot.se>
Date: Mon, 02 Jun 2025 14:17:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dnsop WG <dnsop@ietf.org>
Content-Language: en-US
From: Christian Elmerot <christian@elmerot.se>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: RANMARXB5GUWTY7NSIGB76VLA2RUXBAY
X-Message-ID-Hash: RANMARXB5GUWTY7NSIGB76VLA2RUXBAY
X-MailFrom: christian@elmerot.se
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Updates to draft-huque-dnsop-multi-alg-rules
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BezZYckpODo4ix_nnEJNUPT6A8c>
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>

The draft document for Multiple Algorithm Rules in DNSSEC: 
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-alg-rules/ has 
been updated to version 5

Beyond mainly editorial updates, the new draft adds the additional use 
case for performing independent algorithm roll for KSK/ZSK, letting you 
perform the algorithm roll for the KSK first and later ZSK (or vice versa).

TL;DR: This draft updates DNSSEC signing and validation rules for more 
flexible handling of multiple algorithms. The current specifications 
requires zones to be signed with all advertised algorithms. The draft 
proposes fixes to this by defining 'universally supported' algorithms 
and generally requiring a single signature from one of these, enabling:

  - Multi-signer DNSSEC where providers use different algorithms.
  - Zone transfers in signed state between providers having differing 
algorithm support.
  - Simpler algorithm rollovers. Avoids lengthy and risky double-signing 
periods and allowing pre-publication of new trust anchors.
  - Reducing online signer load in multi algorithm scenarios