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

Paul Wouters <paul@nohats.ca> Wed, 22 May 2024 00:45 UTC

Return-Path: <paul@nohats.ca>
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 EC8B6C1E6415 for <dnsop@ietfa.amsl.com>; Tue, 21 May 2024 17:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.429
X-Spam-Status: No, score=-1.429 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wRFGYErgqBhO for <dnsop@ietfa.amsl.com>; Tue, 21 May 2024 17:45:44 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A532CC1E7252 for <dnsop@ietf.org>; Tue, 21 May 2024 17:45:44 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4VkXfD6xlnzD0X; Wed, 22 May 2024 02:45:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1716338740; bh=4PNKSBY30lhvYpjBrPWEa4olorpqhIkloO+ZKhbkxJI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Lto8BbCKjxGHEjo9xtlNRLWyHih+EU3LP6gjX83pxm/OeHu4KUeBD4f5HbdDaWK4a gistXtBIEtJMZTYEvkZdB5DtEe96IqboCw4u1U+D2zVxuIkTDkLHHxlxbu6X9Kdo4j xUSl7O2HwBQkX4o6KxGIG+LQ1yJYVH3FozVDl4yY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lBzV8x6O7Cu6; Wed, 22 May 2024 02:45:39 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 May 2024 02:45:39 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D7E6611FE74F; Tue, 21 May 2024 20:45:38 -0400 (EDT)
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id D501811FE74E; Tue, 21 May 2024 20:45:38 -0400 (EDT)
Date: Tue, 21 May 2024 20:45:38 -0400
From: Paul Wouters <paul@nohats.ca>
To: Steve Crocker <steve@shinkuro.com>
In-Reply-To: <CABf5zvJLb9vA3fo8JT6jTHROzMda7vqdUcQh7cDzhDSEepQFzA@mail.gmail.com>
Message-ID: <f5dab75c-174c-0115-41e9-4baff95fae01@nohats.ca>
References: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com> <CABf5zvJLb9vA3fo8JT6jTHROzMda7vqdUcQh7cDzhDSEepQFzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-MailFrom: paul@nohats.ca
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: 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>
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>

On Sun, 19 May 2024, Steve Crocker wrote:

[speaking as individual only]

> In my view, an algorithm moves through seven phases during its lifecycle.
> 1. Experimental – defined and included in the IANA registry 
> 2. Adopted – begin inclusion in validation suite
> 3. Available – ok to use for signing
> 4. Mainstream – recommended for signing
> 5. Phaseout  – transition to newer signing algorithm
> 6. Deprecated  – signing should have stopped
> 7. Obsolete  – ok to remove from validation suite

This is a very theoretical transition in an ideal world. But that's not
how things have gone in the past. GOST went from 3 to 7. SHA1 went
from 5 to an unlisted state of "6 but avoid because broken at some OSes".

Also you can't have validation without signing so implementation wise
2 and 3 are the same state.

There is also no "Mainstream". For example some crowds need to follow
FIPS, while other crowds try to avoid FIPS algoritms.

There is also a huge difference in "supported by no one uses it" and

An example over at TLS/IPsec, right now PCI DSS got rid of ffDH. Is that
now no longer Mainstream or is it still Mainstream ?

I think it is better to just have humans evaluate every few years and
come up more flexible transitions. Sometimes that means it doesn't
follow the above 7 steps though in general you'd hope something along
these lines things would be done.

> Each transition from one phase to another should be controlled by an expert group that advises IANA.  (In some cases, an
> algorithm might be deprecated before reaching the "Mainstream" stage.)

There is a lot of interaction based on certifications, payment
industries, webPKI, laws and cryptographic research.

> Comment: In the recent Red Hat snafu, I heard a comment that it was not possible to disable use of an algorithm for
> signing without also disabling the algorithm for validation.

Note everything is possible. It is just that the system's crypto
parameters are being controlled centrally using "crypto-policies"
and require manual tweaking to work. See "man crypto-policies".

For example on the fedora-40 version of crypto-policies:

            The DEFAULT policy is a reasonable default policy for today’s standards. It allows the TLS 1.2, and TLS 1.3
            protocols, as well as IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they are at least 2048
            bits long. This policy provides at least 112-bit security with the exception of allowing SHA-1 signatures in
            DNSSec where they are still prevalent.

Older versions of the crypto-policies had "sha1_in_dnssec" as option,
but the current man page states to use the @DNSSec keyword instead:

 	sha1_in_dnssec: Allow SHA1 usage in DNSSec protocol even if it is not present in the hash and sign lists
 		(recommended replacements: hash@DNSSec, sign@DNSSec).

> Hence, when Red Hat wanted to shut off use of an algorithm
> for signing, it removed it from the crypto suite and thus disabled validation.

It's more complicated. It disabled it but the dns software initially all
just got crypto errors for the verify operations and thus returned
ServFail. One had to recompile with --no-sha1 to ensure sha1 signatures
were treated as unsigned data and skipped validation and were returned
to the client without AD bit set - avoiding the servfail. Then DNS
software started probing for working/not-working algo and handle this
more dynamically.

> While it's understable that a
> straightforward implementation of a crypto suite might provide the same path to an algorithm irrespective of whether it
> will be used for signing or validation, it is possible provide distinct paths for these two uses and thereby permit
> validation but not signing during phases 2 and 6 at the beginning and end of the algorithm's life cycle.

The problem lies in certifcations. If you have "some uses allowed" it
becomes extremely complicated to prove you are compliant, and you
have to make a case to auditors to prove "not doing this makes the
system only weaker, and we guarantee this extra code doesn't cause
different consumers from accidentally validating this".

Yes, your 7 step program is great theory. But in practise it just
won't be happening that often. Just like people tend to ignore
our advise until something breaks and only then will they update
their configs/OS/regulations. SHA1 was signing was "NOT RECOMMENDED"
since June 2019. In October 2020 RSASHA1 finally got mostly turned off.
In June 2021 there were still 2M RSASHA1-NSEC3 which finally got mostly
turned off in Oct 2021. Are those the points where we could have said
NO to sha1? Based on numbers yes, but what if a super important domain
would still be using sha1 then?

As such, I don't see a value in publishing an RFC with this lifecycle
recommendation. It is already known and taken as input. But when the
rubber meets the road we have to do things. I think one of the things
we haven't done well (with DNSSEC, IPsec and to a point TLS) is that
we didn't get rid of old things fast enough. But that is not solved
by publishing more RFCs with MUST NOT. It is an interaction with the
world to push them off these things where at some point we can give
a final nudge to say "really, dont". Another great example here is
IKEv1 which was obsoleted by IKEv2 in 2005 but only in April 2023
did we dare to finally say "really, don't" in RFC9395.