Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Paul Hoffman <> Fri, 25 December 2020 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A1873A0978 for <>; Fri, 25 Dec 2020 12:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FoILkbiTvI8z for <>; Fri, 25 Dec 2020 12:27:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A7FB3A0977 for <>; Fri, 25 Dec 2020 12:27:11 -0800 (PST)
Received: from ( []) by ( with ESMTPS id 0BPKR8xt024816 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Fri, 25 Dec 2020 20:27:09 GMT
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Fri, 25 Dec 2020 12:27:07 -0800
Received: from ([]) by ([]) with mapi id 15.02.0721.006; Fri, 25 Dec 2020 12:27:07 -0800
From: Paul Hoffman <>
To: dnsop <>
Thread-Topic: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Thread-Index: AQHW2iK2rfUUDm/KeUelowK7yn3CSKoIyneA
Date: Fri, 25 Dec 2020 20:27:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_2999D2AC-E2AF-4950-82F5-32FB4D6EA63C"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-25_12:2020-12-24, 2020-12-25 signatures=0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Dec 2020 20:27:12 -0000

On Dec 24, 2020, at 10:28 AM, Daniel Migault <> wrote:
> Hi, 
> As the DNS is a global shared resource and its reliability is based on **all** pieces of software adhering a common standard, I am inclined to believe that new cryptographic algorithms introduced with anything less restrictive than "IETF Review" - such as "Specification Required" and "RFC Required" - does not sufficiently prevent altering the interoperability of the DNS.  

Why do you feel that DNSSEC has requirements stronger than other IETF security prot0cols such as TLS, IPsec, S/MIME, and so on? 

> This is likely to result in the introduction of potentially weak - and unmanageable - cryptography, a fragmentation of the DNS name space, as well as the introduction of policy matters within the IETF.

How would that happen? The developers of DNSSEC signing and validating software are intelligent, thoughtful people.

> Typically, some code points will be qualified as **standard** while others will be **non-standard**. This may put the IETF in a position to define that the trust of community C1 in algorithm A1 is non-standard while the trust of  community C2 in algorithm A2 is standard.

Exactly right. DNSOP has already done that by adopting the GOST standard, which is only of interest to Russia (and maybe a small number of other countries). GOST is a standard *only* for DNSSEC, not for the other IETF security standards, which seems quite out of balance.

> I believe we should avoid this path.
> In addition, I also believe that "Standard Track" is the appropriated status. While a call for adoption of a cryptographic algorithm with a "Standard Track" asks pretty clearly the community on whether they are willing to see that algorithm being deployed. The same call for adoption with another status is less clear and people may not feel concerned which will make it harder to judge the consensus. It is also envisioned that calls for adoption will have an extra round of discussion over the status which I am not sure is necessary. 
> As a result, I am inclined to believe we should not adopt draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014.

What has changed since DNSOP discussed and adopted RFC 6014 that would make us want to do that? 

--Paul Hoffman