IETF Logo Mail Archive

Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC

Paul Wouters <paul@nohats.ca> Mon, 11 April 2022 13:00 UTC

Return-Path: <paul@nohats.ca>
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 CA2193A0E7A for <dnsop@ietfa.amsl.com>; Mon, 11 Apr 2022 06:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SDf-3MlQeSU for <dnsop@ietfa.amsl.com>; Mon, 11 Apr 2022 06:00:53 -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 460083A0E17 for <dnsop@ietf.org>; Mon, 11 Apr 2022 06:00:53 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KcTVp0Tk5z38F; Mon, 11 Apr 2022 15:00:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649682050; bh=e1JzFhO45eXuwi0qh9Vh0eo9Y3FhEjhkipUUL+XXyNc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mAnbfG0cC3SvGMBzdJnjq/Uofw/oPRlE145YnfjGsP/+QkAjVtClXKcNU7vIvoetS pxx1ZFVl6m8CMjiC2bmxlbWxmHfgj8aPAtOYL63Pn4ZUBggX4e8Tt/XPKvs5SUtUz/ /SyCgu1X69HMmgqZ5gcV1K6dRbA8QwVP1j47t8+Q=
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 MEYFV11Lkt73; Mon, 11 Apr 2022 15:00:48 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 11 Apr 2022 15:00:48 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8941D2DF2A3; Mon, 11 Apr 2022 09:00:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 85A772DF2A2; Mon, 11 Apr 2022 09:00:47 -0400 (EDT)
Date: Mon, 11 Apr 2022 09:00:47 -0400
From: Paul Wouters <paul@nohats.ca>
To: zhangcuiling <zhangcuiling@cnnic.cn>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <202204111111585901567@cnnic.cn>
Message-ID: <4af2f29f-b2ac-b2e7-e977-793461adfda5@nohats.ca>
References: <202204111111585901567@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6ppU9O__69LWvuuPIpFk6phns9E>
Subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2022 13:01:06 -0000

On Mon, 11 Apr 2022, zhangcuiling wrote:

> And the main purpose is to improve the diversity of DNSSEC algorithms, and to make it convenient for people who want to use SM2
> digital signature algorithm as an alternative for DNSSEC.

We actually want to prevent as much diversity as we can, to avoid
creating more new long tails of deployment of algorithms. So a new
algorithm should really offer something the others do not. Also having
a number of ECC based algorithms would likely mean if one ends up
broken, all of them end up broken.

So based on:

 	Due to the similarity between SM2 and ECDSA with curve P-256, some
 	of the material in this document is copied liberally from RFC 6605
 	[RFC6605].

I don't see a strong reason to adopt another ECC type of algorithm.

Additionally, in this case SM2/SM3 seems to be ISO standards that are
not freely available, so these are additionally problematic.

Paul

v2.23.0 | Report a Bug | By Email