[secdir] Secdir telechat review of draft-ietf-dnsop-rfc8624-bis-09

Magnus Nyström via Datatracker <noreply@ietf.org> Wed, 16 April 2025 16:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@mail2.ietf.org
Received: from [10.244.8.129] (unknown [104.131.183.230]) by mail2.ietf.org (Postfix) with ESMTP id B7E821D21730; Wed, 16 Apr 2025 09:38:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Magnus Nyström via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <174482152760.1487869.12653767966782787610@dt-datatracker-64c5c9b5f9-hz6qg>
Date: Wed, 16 Apr 2025 09:38:47 -0700
Message-ID-Hash: KJGXMVFR32AKDIT2LKNULNKJWO6L3ZPN
X-Message-ID-Hash: KJGXMVFR32AKDIT2LKNULNKJWO6L3ZPN
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, draft-ietf-dnsop-rfc8624-bis.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Magnus Nyström <magnusn@gmail.com>
Subject: [secdir] Secdir telechat review of draft-ietf-dnsop-rfc8624-bis-09
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/C8eovwuMpBhODeRsHH0E9NGeaIE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Document: draft-ietf-dnsop-rfc8624-bis
Title: DNSSEC Cryptographic Algorithm Recommendation Update Process
Reviewer: Magnus Nyström
Review result: Has Nits

Firstly, I want to thank the authors for doing updates based on my previous
review. There is still one small edit I would like to see: In the Security
Considerations section, when talking about algorithm deprecation due to an
algorithm no longer being cryptographically secure, we went from:

"Therefore, algorithm deprecation must be done very slowly and only after
careful consideration and measurement of its use." (which I felt was in need of
update since "very slowly" is indeterminate and, not even always possible -
e.g., in the case of a catastrophic break of an algorithm)

to:

"Therefore, algorithm deprecation must be done only after careful consideration
and ideally slowly when possible."

The new statement is clearly better, but I still feel that the "and ideally
slowly when possible" part is needless and potentially confusing. "Careful
consideration" to me implies that you go slow, if possible. And there is also
the preceding sentence: "Retiring an algorithm too soon would result in a zone
signed with the retired algorithm being downgraded to the equivalent of an
unsigned zone" which calls for a measured approach, if possible. So, while I
would rather not include that sentence ending, it is no longer an issue for me.

Thanks,