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

Paul Hoffman <> Fri, 01 January 2021 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4E913A00F7 for <>; Fri, 1 Jan 2021 08:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uXD-tleemYPz for <>; Fri, 1 Jan 2021 08:38:08 -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 931863A00E9 for <>; Fri, 1 Jan 2021 08:38:08 -0800 (PST)
Received: from ( []) by ( with ESMTPS id 101Gc3qZ002858 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Jan 2021 16:38:04 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, 1 Jan 2021 08:38:02 -0800
Received: from ([]) by ([]) with mapi id 15.02.0721.006; Fri, 1 Jan 2021 08:38:02 -0800
From: Paul Hoffman <>
To: Stephen Farrell <>, Eric Rescorla <>
CC: dnsop <>
Thread-Topic: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Date: Fri, 01 Jan 2021 16:38:02 +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=_D65046FB-CCCE-4D9F-822B-804241380DFD"; 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=2021-01-01_07:2020-12-31, 2021-01-01 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, 01 Jan 2021 16:38:10 -0000

On Dec 31, 2020, at 2:09 PM, Stephen Farrell <> wrote:
> Hiya,
> On 31/12/2020 21:48, Eric Rescorla wrote:
>> 1. Don't allocate a code point at all
>> 2. Allocate the code point but in some manner that makes clear
>>    we don't endorse it (effectively what TLS does for algorithms
>>    like this)
>> 3. Allocate the code point without comment
> FWIW, I kind of agree with ekr, both as to the options
> and on my current preference to not too easily loosen
> up for DNSSEC.

To be clear, the loosening that is being discussed is from making it "standards required" to "RFC required". (We briefly discussed going to "specification required", but there was little appetite for that.)

> That said, I wonder as to the actual deployment of algs
> that we'd not recommend, especially given the relative
> scarcity of DNSSEC signing.

Well, exactly. This discussion arose because a few Russian folks want the revised GOST algorithms to have a code point allocated. Currently, for them to do that, the IETF would have to put the new GOST algorithms on standards track. We did that for the last algorithm, but it is not clear if we want to do that again. 

> Does anyone have a pointer to survey-like material that
> has a focus on rarer algorithms in DNSSEC? One reason to
> ask is that from a first glance it looks to me like .ru
> isn't using gost, which would be telling, if correct.
> To be clear: I don't think spending much time debating
> how to handle algs for an infinitesimal number of zones
> is that worthwhile, so that'd be another reason to prefer
> the status quo, if that is the case.

The status quo (standard required) will likely absorb a lot of time for the IETF if the WG decides to move the revised GOST forward. It will also probably land in the CFRG. Reducing the requirement to RFC required allows their document to be informational.

The WG already has RFC 8624 that talks about what implementers should do with various algorithms. Clearly, it will need to be updated for the revised GOST regardless of whether the WG changes the IANA considerations.

Also, as a reminder, this isn't only about GOST. In the coming years, there will be a raft of post-quantum signing algorithms with different signature and key size ratios that people will want adopted. Putting every one of them on standards track seems onerous to some of us.

--Paul Hoffman