Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

Paul Wouters <> Mon, 10 July 2017 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53B7013193E for <>; Mon, 10 Jul 2017 15:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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] 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 4moH3YhzkuB6 for <>; Mon, 10 Jul 2017 15:55:34 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4A0413193D for <>; Mon, 10 Jul 2017 15:55:33 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3x60t90wC4z1Gp; Tue, 11 Jul 2017 00:55:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1499727329; bh=p+7xd8YEK/RVs7nkxFJODAtd4znwafrR31LYWFGS6d8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=c/rBTqXtVqk7ZJMISFYSDhzIImEld+kCtbqouwSTLPDw9rayHaTisp0OcS955+QJk Qfh91crfpF4iFcmx3GZ+W5eZLN2Nx4goBjZK4h915IP6KGpP+wYaTUa+DPPStHyIaB FGfkA2kOAaDmQke/1ZnvriUzzgvSOcazQRfxakrU=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jUNrWcfbsGl3; Tue, 11 Jul 2017 00:55:27 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 11 Jul 2017 00:55:26 +0200 (CEST)
Received: by (Postfix, from userid 1000) id ADCAF30AF11; Mon, 10 Jul 2017 18:55:25 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 ADCAF30AF11
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9809640D3592; Mon, 10 Jul 2017 18:55:25 -0400 (EDT)
Date: Mon, 10 Jul 2017 18:55:25 -0400 (EDT)
From: Paul Wouters <>
To: Shumon Huque <>
cc: " WG" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC
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: Mon, 10 Jul 2017 22:55:36 -0000

On Mon, 10 Jul 2017, Shumon Huque wrote:

> Perhaps we didn't explain it clearly enough, so let me give you a concrete example:
> My zone is currently signed with 2048-bit RSASHA256. I want to offer signatures with Ed448 (or some other new algorithm) also, so that
> newer validators can take advantage of it. However, I want to be able to continue to support the current population of validators that
> don't support Ed448 until a sufficient amount of time has passed where they have all been upgraded - this could be some number of years.
> I also don't want to double sign the zone and return multiple signatures in the responses, because they might be fragmented and cause
> timeouts and retransmissions at the client (validator) end. I could truncate those responses and prompt them to re-query over TCP, but
> then again I have caused an unnecessary failed roundtrip and have incurred additional processing costs associated with TCP, and maybe I
> haven't scaled up my authoritative infrastructure sufficiently to deal with that.
> I also don't want to deploy only Ed448 and cause my zone to be instantly treated as unsigned by the vast majority of resolvers. Obviously,
> because I've nullified the security benefit of DNSSEC, but also because I have application security protocols, like DANE, that critically
> depend on DNSSEC authentication, for which this would pose a grave security risk.
> So the goal is not to have them "permanently" signed with multiple algorithms, but for a defined transition period, which may not be very
> short. At that point, the older algorithm would be withdrawn -- so algorithm rollover, but over an extended period.

Okay, that explains it better. but does also confirm you basically want
to be permanently in this state. Because every few years you will have
new fancy algorithms. As a community we should really roll out updated
algorithms faster and deprecate obsoleted algorithms faster.

> Of course there are initial costs. The goal is longer term - the benefits will increase with more adoption over time. There will be a lot
> of large responses initially, which will decrease over time.

But then why not depend on adoption of (and deprecation of) old signing

>       One would hope zones are migrated from "strong" to "even stronger"
>       algorithms, and not from "weak" to "strong enough", so I don't think
>       algorithm downgrade is ever an issue.
> Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is the butt of jokes in the larger security community.

You are mixing up keysize and algorithm rollover :P

RSA is not broken, and safe to use, preferably at 2048 key size. No double
signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :)


 	"The overwhelming majority (~99%) of TLDs use 2048 bit keys"

I can't find a statistics URL for all domains (secspider seems to have
changed and I cannot find the RSA key sizes per domain anymore) but I'm
pretty sure 1024 will be on the decline.

Anyway, my point is that we should not have 20 sexy algorithms, but only
a very limited set of a few algorithms that we all agree are strong
enough. We shouldn't enter into negotiations of prefered crypto
algorithms between auth and recursive servers.

And once opendnssec algorithm rollover is available from stable
distributions, I think we will see most zones go from RSASHA1 to