[DNSOP]Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

Warren Kumari <warren@kumari.net> Tue, 14 May 2024 20:57 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 41E8BC1840C3 for <dnsop@ietfa.amsl.com>; Tue, 14 May 2024 13:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, 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=kumari.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E1Y_fsAK-2Lf for <dnsop@ietfa.amsl.com>; Tue, 14 May 2024 13:57:45 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF571C18DA05 for <dnsop@ietf.org>; Tue, 14 May 2024 13:57:45 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57342829409so2080834a12.1 for <dnsop@ietf.org>; Tue, 14 May 2024 13:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1715720263; x=1716325063; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=7eWgG+Vmnk3nKuqRx/lcjThhYLvwSNAEYutzeCl8n0Q=; b=cO9//6sJ7b5lZ5mc5z1N/40YT9M6R7/se7LY8ytZyZpk7Z4me3eiBLHiSowKo+cEov 4Lq/r0T3a5cicx2TZ9CPXhtJ6Emom3JPn6JiFoUfjt5DRyNg8PLadeW76cL0S3Lq1Jr3 f2TrngKfS9nF57zgrlBj+XbT3W0zmjRd9jgmXrQ7GCE/vmal+y75+p+UYiSJ2edayAn+ Tv/RDeqCMo1TYDVbTU9LQ0C1AC8vzrcERCF2DcdqlaUeI2tz2wcMqBWG20zD4CqeRaG2 +OZpgR3J7faBlj892wLpegl8sVkULr6tevHh3ehvhUPVd4nj4JS/edia/Ud2jVHlj5xE nrgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715720263; x=1716325063; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=7eWgG+Vmnk3nKuqRx/lcjThhYLvwSNAEYutzeCl8n0Q=; b=imPE4TXLmFBGPFCc/ZIckWiXzo+R3yK9Zf4fe8GGk5n7hfdk5bhH7p4erjpk0lqyBW SMj5X+Qk9OQ8m/yFOAbaYe9sSp+pdBrs8AVL1KYXHpHCDcp2PGbtVtM91/IMMljqEmrN RVrTTWTuWaZxB3mxQwX6n1SyB0EgOv0P7dmXxl14WnQq1o899rorsn3AyAtaIUgQ1Z3W YnuNuy8JGrGHsWNn53IpbWHElBwZO9zVC1HoGFUgfODPx8TsqUQeGgYXT/D3zHRAB4kE TniAU/gF9V2ltOie4gl/mBupQfE6Df26vfiE1WYzMXiCTjfdAKJS4IH6I81SHpjGzZtx iKfg==
X-Gm-Message-State: AOJu0Yzrw1X0BLk67Sg0WKMvtF3R39DbdWMWIp6NAeb4y8vgMl4xm+Je DYpSzenAMKgfoihcJoEJjuEHr+B01D2yuX7oREbk9HvPtxvp6q7LXKtevO9pfXCkJmIUD13ps62 TsZ82hMnIApzwZfwjLmuYklYsDCUgFnLvS+macVDK/gC0V+N7
X-Google-Smtp-Source: AGHT+IEng3kL8vZ2d/cqiCedVqAq5aXSKnmoE16yTQN+IgBZI46goEEpb7Qqcn2QCOsBgYQ8HefU0ekrIr0CuG1KP54=
X-Received: by 2002:a50:ab19:0:b0:574:ec3d:262a with SMTP id 4fb4d7f45d1cf-574ec3d28d3mr1499598a12.5.1715720263147; Tue, 14 May 2024 13:57:43 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Tue, 14 May 2024 16:57:41 -0400
Mime-Version: 1.0
X-Superhuman-ID: lw6vj6d2.0440e14f-6d11-452b-80a2-42a3f5ab5081
X-Superhuman-Draft-ID: draft00abb292ad4764de
X-Superhuman-Thread-ID: draft00005a9e31cbe299
X-Mailer: Superhuman Desktop (2024-05-14T19:05:52Z)
From: Warren Kumari <warren@kumari.net>
Date: Tue, 14 May 2024 16:57:41 -0400
Message-ID: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d1bb630618704099"
X-MailFrom: warren@kumari.net
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.9rc4
Precedence: list
Subject: [DNSOP]Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eUA-qInUmKwQQYFQBKab8aJbMIE>
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>

Hello everybody,

Firstly thank you for all of the discussion on these documents - we really
appreciate the review and feedback.

We’ve read all of the discussion(s) and will be updating the documents to
address your comments, based on our understanding of the group’s consensus
so far. While reviewing the discussion, we came to the realization that
there are two potential paths forward for draft-hardaker-dnsop-rfc8624-bis,
and we would like your opinion on which choice everyone feels is best.

As evidenced by the discussions, implementations can’t realistically remove
the Foo algorithm if many of their customers are still using it. So:

Option 1: Pivot this document from providing implementers with guidance
(“Implementers MUST NOT use Foo for signing”) to providing guidance to
operators instead (“Operators MUST NOT use Foo for signing”).


Option 2: Focus on removing algorithm usage first, by informing operators
to stop using an algorithm to be deprecated, and then, later, specify that
implementers may/should/must stop supporting the algorithm.

We think Option 2 makes much more sense, as this provides both “operational
guidance” and “implementation guidance.”  With such, we can leave
implementations interoperable while slowly decreasing algorithm deployment
until it is safe to actually remove implementation support once perceived
usage has decreased. If we were to provide guidance to either implementers
or operators -- but not both --  then we leave one side questioning their
purpose in life.

This means that we should actually have a column per type (i.e “Operators”
and “Implementers”) crossed with a column per DNSSEC usage type (“Signing”
and “Validation”), such that for the “Domain Name System Security (DNSSEC)
Algorithm Numbers” table we would be adding FOUR columns:


   “Use for DNSSEC Signing”

   “Use for DNSSEC Validation”

   “Implement for DNSSEC Signing”

   “Implement for DNSSEC Validation”

And four for “DNSSEC Delegation Signer (DS) Resource Record (RR) Type
Digest Algorithms”:


   “Use for DNSSEC Delegation”

   “Use for DNSSEC Validation”

   “Implement for DNSSEC Delegation”

   “Implement for DNSSEC Validation”

With these in place, drafts like the draft-hardaker-dnsop-must-not-sha1can
be written with each recommendation to be  discussed individually.

Note that we have not updated the text in the repository yet as this would
be a fairly major overhaul, and we wanted to get the working group’s
opinions on the subject first.

Wes and Warren

P.S: When reading the thread, we suddenly realized that the
“draft-hardaker-dnsop-must-not-gost” document needed even more
clarification that it is only talking about the “old” GOST (RFC5933), and
not the “new” GOST (RFC 9558).

The “old” GOST RFC was made historic (see “Change the status of GOST
Signature Algorithms in DNSSEC in the IETF stream to Historic” -
). Old GOST was “deprecated by the Orders of the Federal Agency for
Technical Regulation and Metrology of Russia (Rosstandart) in August 2012,
and superseded by GOST 34.10-2012 and GOST 34.11-2012 respectively from January
1, 2013), which provides a good justification. This means that we can
remove the “The security of the ECC-GOST algorithm [RFC5933] has been
slowly diminishing over time as various forms of attacks have weakened its
cryptographic underpinning.”  hand-wavy justification.