[DNSOP]Further comment re algorithm life cycles

Steve Crocker <steve@shinkuro.com> Sun, 19 May 2024 17:22 UTC

Return-Path: <steve@shinkuro.com>
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 2F9F5C14F6BE for <dnsop@ietfa.amsl.com>; Sun, 19 May 2024 10:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=shinkuro-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uZ3EUKghYiFb for <dnsop@ietfa.amsl.com>; Sun, 19 May 2024 10:22:09 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 31B76C14F6A1 for <dnsop@ietf.org>; Sun, 19 May 2024 10:22:09 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-6ed3587b93bso1894069a34.1 for <dnsop@ietf.org>; Sun, 19 May 2024 10:22:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20230601.gappssmtp.com; s=20230601; t=1716139328; x=1716744128; 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=V6KTkvPTeGn6NS1Ptr9vlGLMZK993XEb5s2lBDxVVfE=; b=PApfTilm+OWxFREu+8Jf1Zr5U4PyG8X/rb0dqQS/zteQULrYZ85RMciY/lKB5Murrt 33aSpTCi8ROIf02jqOficbOgZVKbixgwv5yqA7BzsaKM2t2sAyedfvrAEopXL+Md9lns W9A0s2R1RXtlAVmMr5g9WYuks8Mq6IPMZUBnMz5lzouTrmrxxQj3zic3w8ObBWZrPQHw A1LSoKa24o2wpqcHxFSzUtetJ2st63F9vZWEGWtSqq0Acev5GsXVSKj1vku+x5LBgeD8 CCiwWRaeiLxvDFQ9p4GvTb8hkBLgZwwNF4zapC5qqwre2905BAMwI6pdHrCfgIXgNh9b Zl+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716139328; x=1716744128; 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=V6KTkvPTeGn6NS1Ptr9vlGLMZK993XEb5s2lBDxVVfE=; b=iH4tP7uN1tlTeGRx9IBYvsPLqx5oXP/vhYFq16OStivdck6bImVAYHvEZpoJdE2TTv VauQeUm/P0sqinITedx26zoAtlW4PwLXXNJFPsnLawKWA1OzALHlkvdjV6QFtkov1MIc KVI9FkHEI1BfxOOUHXLstz2CVSYVcFHD6X2JH26QbbToc0MNX70Dg0d/0hx7ngTRBaiZ mLrqVa+9X5ur2BcueuDUJDMNxPgGJgd+Zatuwi3/it+dRwbZRlrWSmrP+G6Fgk7jBBuV Q1d8Wv/7TyxDDsS94VTgS6haBFhGIdiZAH9Na7NFgpA/zbK8iAgOJ5KMe9id+zKpa9FB vxew==
X-Gm-Message-State: AOJu0YwySNn63hGwxykZsx571Px+4invW3Kt240tOt5PFfI95dsJHI55 0cp3ZwbP7m2515utIeDeuwC8Lglbk0sE+rWdKnzASr9C6WljgzanCmEmNO7Q1dWERCq9QR5VW2q SJK3HKtL8p3ZJhpPX/p0oT4YvSbclBdyJ+l8aDgnKRdAixBHo
X-Google-Smtp-Source: AGHT+IFEICO37sgz7SKOBoCoFOszPSdbUwshJWP+wThmXW65eDT47aRO86uiETz1ytkU1ndAgn94gjcsKAgt9Fnvy1I=
X-Received: by 2002:a05:6830:1e41:b0:6f0:df20:4788 with SMTP id 46e09a7af769-6f0e91310f7mr28842230a34.14.1716139327782; Sun, 19 May 2024 10:22:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com> <CABf5zvJLb9vA3fo8JT6jTHROzMda7vqdUcQh7cDzhDSEepQFzA@mail.gmail.com>
In-Reply-To: <CABf5zvJLb9vA3fo8JT6jTHROzMda7vqdUcQh7cDzhDSEepQFzA@mail.gmail.com>
From: Steve Crocker <steve@shinkuro.com>
Date: Sun, 19 May 2024 13:21:56 -0400
Message-ID: <CABf5zvLetqCakV9s0ma9owFo-hFbJ57dz7B4v_xK+bSdFJVrfg@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>, Wes Hardaker <hardaker@isi.edu>
Content-Type: multipart/alternative; boundary="00000000000004a2900618d1d37a"
X-MailFrom: steve@shinkuro.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]Further comment re algorithm life cycles
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l3vnBVxGP0pWdJKROtqHbrMd58E>
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>

Under the heading of saying what might be obvious but needs to said anyway,
there should always be at least one mainstream (phase 4) algorithm in use.
When an algorithm is moved to phaseout (phase 5), there should already be
one or more other mainstream algorithms in use.

On Sun, May 19, 2024 at 1:11 PM Steve Crocker <steve@shinkuro.com> wrote:

> Warren, Wes, et al,
> TL;DR: Yes and No.
> Yes: Thanks for the initiative to move this into an IANA Registry.  This
> is the right idea, and what I've been advocating for the past many months.
> No: I don't think the scheme is quite right.
> 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
> 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.)
> When I try to reconcile the above with 8624 bis-03, there are some rough
> edges.  The table below represents my view of the preferred words to use in
> Table 2 in 8624 bis-03
> Phase    Signing           Validation        Algorithms
>   1      Must Not          May
>   2      Must Not          Must
>   3      May               Must              (8) RSASHA256, (13)
>   4      Recommended       Must              (15) ED25519
>   5      Not Recommended   Must              (5) RSASHA1, (7)
>   6      Must Not          Must              (12) ECC-GOST
>   7      Must Not          Must Not          (1) RSAMD5, (3) DSA, (6)
> I'm not sure where to place algorithms (14) ECDSAP384SHA384 and (16) ED448.
> They're marked as MAY/RECOMMENDED in 8624 bis-03, and I assume they're in
> the early part of their life cycles, so I'm inclined to put them in phase
> 3, but I don't see how to distinguish their status from (8) RSASHA256,
> (13) ECDSAP256SHA256.  Or perhaps these are in phase 5, which leads to the
> question of how to distinguish them from the ones listed in phase 5.
> Implementers and purveyors of crypto suites should treat May, Recommended
> and Not Recommended as equivalent to Must.  The distinctions among these
> terms are intended for usage of these algorithms, not the implementation of
> the crypto suite.
> 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.  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.  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.
> Thanks,
> Steve
> 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
> --
> Sent by a Verified
> [image: Sent by a Verified sender]
> <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
> sender

Sent by a Verified
[image: Sent by a Verified sender]