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

[Paul Wouters <[e-mail]>]

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
algorithms?

>       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 :)

also: https://www.internetsociety.org/doc/state-dnssec-deployment-2016

 	"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
RSASHA256 or ECDSA.

Paul