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

Tim Wicinski <tjw.ietf@gmail.com> Wed, 19 June 2024 14:56 UTC

Return-Path: <tjw.ietf@gmail.com>
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 C7C16C1CAF29 for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2024 07:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.com
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 r6YKdHLWPFZj for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2024 07:56:16 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C242CC14CE31 for <dnsop@ietf.org>; Wed, 19 Jun 2024 07:56:16 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-57d05e0017aso1746087a12.1 for <dnsop@ietf.org>; Wed, 19 Jun 2024 07:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718808975; x=1719413775; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NLYdBrxTvx3ZR4X4vYQhMPXKZt6/vy/st6ao2+rui7c=; b=KXUXNAr+StPfT8tjptI7+En9+htOKkZy0nAkRtQTkWoluBSC0YSAAsBaIt8Q1kFyZo IRPe7svZHEaUB4YUeQkE+07730aGeJXeikFx8IyhWxhaKjmsqozMWlLRcUzlABWQX/yF zLKo31Qnx9bUJirB8LssHjcW0CS7uCTRwBxIeN12D4p9q1QpuI83TGzQDvcyAlas+FRM KOU87q8C6tSrORlJyCBhGGPpbV4WCHhI5KdbLeIorRHrlLIXY5FIURhpjEWTzFlyjTf7 1gVM9+FHIwK4qtgXoBXmAIMDqUQPpJtXVuCeDL9C9CvYg3d+8eo+AvN1j+J/0XKFuQ+c zQxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718808975; x=1719413775; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NLYdBrxTvx3ZR4X4vYQhMPXKZt6/vy/st6ao2+rui7c=; b=gxSxhiqJ8+mWRRTgRD/MHfA25pod0HjzdzVzIwRx0twIgqVqs17y81ive4W6LNMLg/ sZj+kcHXvul/MlXuLXSrWax0FgKwwlTvVsIbVe5lphxf9V4hDkikOZ2N3xy2NC0yjcLN q49XFy7AIXnpKwuwH8GxNX0MfOqAclQSNJ1wgg1DvA+VfKcH5R09TNBi8m3zARz7njXU JUthoIG8dNf7LJ36ucsb7wAzGKJBPc7qAmP5R8XOp5ThXcVhojDWTymsVuxAwOGd5cY1 Kh56EotNqlpDertyW0c3O0RElPmRTnVLAx8i4CK3EzpH/qUkn73xlwuV/6XJhm1pAmzR luOg==
X-Gm-Message-State: AOJu0YwAEshgufhZx0yXGeqoZEfx9dUP9RhGZA12VXnRI0tQ9nPqcLNy x37ozYGUj7ycPhS+KEqsiTyvRMDrpYNfN+QaHtZddcxyxKEBGUsfl70YLV/HRZCrCkqQiDCqvte F0ivW6ZdLW21et1X8IbHNfxlFvmsNrA==
X-Google-Smtp-Source: AGHT+IE731g7iyHDurZL6ovhzuEvr5fQNXy8Seftm80XGFQwkB1fgrkrfNstE4Ple0uzzFBS9xcXNpgU+mVXuNnVs3E=
X-Received: by 2002:a50:ab18:0:b0:57d:12c3:eca6 with SMTP id 4fb4d7f45d1cf-57d12c3ed79mr885530a12.18.1718808974480; Wed, 19 Jun 2024 07:56:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com>
In-Reply-To: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Wed, 19 Jun 2024 10:56:03 -0400
Message-ID: <CADyWQ+Gy3+zggx0rcxwvFeTQs2cpf2iotUydJJ1wtHDJnLdn7w@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Content-Type: multipart/alternative; boundary="0000000000005c5d2a061b3f6676"
Message-ID-Hash: EZIDVB3MJEZD5WGGTPI5PINLJ3YZR4C7
X-Message-ID-Hash: EZIDVB3MJEZD5WGGTPI5PINLJ3YZR4C7
X-MailFrom: tjw.ietf@gmail.com
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: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [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/oDD_UY5_FiFYYlDfvylQJvjtqiQ>
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>

All

We chairs wanted to let the working group know that the authors will be
publishing new versions with the recommendations that there is agreement
on.
They are hoping to get all this done before the document submission
deadline (or maybe that was the chair's optimism).


tim

On Tue, May 14, 2024 at 4:58 PM Warren Kumari <warren@kumari.net> wrote:

> <no-hats>
> 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”).
>
> Or
>
> 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” -
> *https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/*
> <https://datatracker.ietf.org/doc/status-change-gost-dnssec-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.
>
> </no-hats>
>
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>