Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

Doug Barton <> Thu, 16 March 2017 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E3DB12025C for <>; Wed, 15 Mar 2017 21:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T185WXl-CgLz for <>; Wed, 15 Mar 2017 21:38:44 -0700 (PDT)
Received: from ( [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 397D21201F8 for <>; Wed, 15 Mar 2017 21:38:43 -0700 (PDT)
Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by (Postfix) with ESMTPSA id E31CD8A for <>; Wed, 15 Mar 2017 21:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1489639126; bh=jmNuoi5crd2PRT0L0QBmLdN4wZVQXEnR+5jkI9D/m5g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cO+DqDKOOZurEgog8iUCHeQGaT3n0j6gRxkU9cU3zaNUhi2uGASLMrWhUGpMeTG0b 5eoksRg9sAPDtUnaNXxjI5z2QvZyNfKyljQ4sTvpZ3sG7dRb9BhS16M2vXNbMGtEmJ GlPIEGrnMCHjKA7ADVFuXnoOC2/Hu8koqmdKBU8Y=
References: <> <> <> <> <> <> <> <> <> <>
From: Doug Barton <>
Message-ID: <>
Date: Wed, 15 Mar 2017 21:38:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Mar 2017 04:38:45 -0000

I can't help finding this discussion funny, as I proposed prior to the 
-bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the 
simple reason that it was overwhelmingly likely that the root would be 
signed with the former, making it as close to mandatory to implement as 
possible without documenting it as such; and the latter as interesting 
as day-old bread.

Now here we are 13 years later, still having the same discussion, 7 
years after the root was signed with (you guessed it) RSA-SHA256. :)

DNS has a long tail indeed.

On 03/15/2017 10:22 AM, Michael StJohns wrote:
> On 3/15/2017 6:26 AM, Roy Arends wrote:
>> In the spirit of being constructive, we (Jakob Schlyter, Matt Larson
>> and I) have written a small draft
>> (draft-arends-dnsop-dnssec-algorithm-update) that does two things:
>> it changes RSASHA1 from “Must Implement” to “Recommended to
>> Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
>> it changes RSASHA256 from “Recommended to Implement” to “Must Implement”.
>> The main motivator for this is that implementors have an incentive to
>> move their implementations “default use” away from RSASHA1 (for
>> instance, when a user generates a DNSKEY without specifying an
>> algorithm, or when choosing an algorithm for signing in the presence
>> of more than one algorithm.

FWIW I agree with Roy that we should make 256 a must-implement ASAP 
(since for all practical purposes it is already), and encourage 
implementors in the strongest possible terms to make it the default.

> Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))

Michael, this is pointless, unless you can demonstrate how an existing 
implementation works without being able to use the root key.

> Must Not Implement:  RSASHA1 (After 1/1/2021)
> Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until
> 5/31/2018)

Mostly pointless, although there was an interesting point raised about 
the difference between producing signatures with SHA1, and being able to 
validate them. Telling people that we're creating a long tail by letting 
them continue to use SHA1 for N years will result in a tail of minimum N 
+ 10 years. So telling people to stop using it NOW is the right answer.

I'm torn on how to deal with validation though. "Compliant 
implementations MUST generate a warning when validating signatures with 
algorithms weaker than RSA-SHA56. Compliant implementations MUST 
generate an error for such algorithms starting 4 years from the 
publication of this document as a draft standard, and unless the records 
are signed with a compliant algorithm they should be considered unsigned."

Something like that, although obviously it needs polishing.