[DNSOP] Re: Mohamed Boucadair's No Objection on draft-ietf-dnsop-must-not-ecc-gost-04: (with COMMENT)

Wes Hardaker <wjhns1@hardakers.net> Tue, 20 May 2025 22:39 UTC

Return-Path: <wjhns1@hardakers.net>
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 842562AEE653; Tue, 20 May 2025 15:39:41 -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=hardakers.net
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 nBSgWLwwcGEq; Tue, 20 May 2025 15:39:41 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2C5D72AEE644; Tue, 20 May 2025 15:39:41 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7802D206CA; Tue, 20 May 2025 15:39:40 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 7802D206CA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1747780780; bh=2+eQME0Cv0eo0x0RemhX2Sw93mHfr6Tn62aLYe/0V6M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nffYD7o79mDtUAzYDplQPdHGjTm5Mj2hXn3zzWA7F5uJwMu2BevAxzuI0NiARlhlB CmDuGSLGpoyLaJqR236qaK452x3PUCQjs9O1BKJolqd8SbU47cCcXJnweObF4OLP7T mXSX+crV+ILdSpqDRtrLSOzXOPB4mwItD36jNc/k=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Mohamed Boucadair via Datatracker <noreply@ietf.org>
In-Reply-To: <174703256318.1524636.7579073644972697579@dt-datatracker-58d4498dbd-6gzjf> (Mohamed Boucadair via Datatracker's message of "Sun, 11 May 2025 23:49:23 -0700")
References: <174703256318.1524636.7579073644972697579@dt-datatracker-58d4498dbd-6gzjf>
Date: Tue, 20 May 2025 15:39:40 -0700
Message-ID: <yblfrgyc3f7.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: ITWK6C6LOWUXYSVHKHKMRLLQXU4HGEH2
X-Message-ID-Hash: ITWK6C6LOWUXYSVHKHKMRLLQXU4HGEH2
X-MailFrom: wjhns1@hardakers.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
CC: The IESG <iesg@ietf.org>, Mohamed Boucadair <mohamed.boucadair@orange.com>, draft-ietf-dnsop-must-not-ecc-gost@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Mohamed Boucadair's No Objection on draft-ietf-dnsop-must-not-ecc-gost-04: (with COMMENT)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eTMnMj_aIsVqlyfAqgQvwQLStTY>
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>

Mohamed Boucadair via Datatracker <noreply@ietf.org> writes:

> # Update
> 
> CURRENT:
>    Updates: 5933 (if approved)

Removed the updates.  Though others may want me to remove the removal.
We'll see :-)

> The update to 5933 is not needed here given that the registry already tags 12 as deprecated.
> 
> # Why a separate document?
> 
> It is tempting to ask why this is not handled as part of
> draft-ietf-dnsop-rfc8624, though.

I think you likely already saw my other responses on this subject.  But
I'll quote myself again here:

So this is where the confusion really comes in and one of the reasons we
wanted to change how this is done.  In the past there were two sources
of information that specified where you should look for current status
of a given algorithm:

1. the IANA tables (which you note deprecates GOST R 34.10-2001).
2. RFC8624 (which talks about implementation requirements and has GOST R
34.10-2001 still listed as MAY)

Thus, the WG decided to:

1. Update 8624 so it no longer contained the implementation guidance and
moved the requirements into the IANA table itself, to address this very
source of confusion.  To ensure that 8624bis would get through without
diving into a debate about particular algorithms, the WG concluded that
8624bis should not change any values at all from 8624 and should just be
about switching how things were done.

2. Issue future documents about changing the values could then be
created to actually make value changes once the IANA registry update was
complete.  The first two documents doing so are the must-not-gost and
must-not-sha1 documents.  These were intentionally written as separate
documents for two reasons:  A) because we didn't know if the WG would
actually want to change those values (IE, it was an independent
discussion) and B) to test the process of the new 862bis procedures.

Technically, the documents could be combined but the history is much
cleaner as 3 separate documents.  In our humble opinion, of course, and
is what the consensus was as well.

-- 
Wes Hardaker
USC/ISI