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

[Shumon Huque <[e-mail]>]

On Mon, Jul 10, 2017 at 6:55 PM, Paul Wouters <[e-mail]> wrote:

> On Mon, 10 Jul 2017, Shumon Huque wrote:
>
>>
>> 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.


I certainly agree with that goal. In practice it is hard to achieve given
the vast population of DNS software and the long tail of feature adoption.

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?


That would be ideal. Again desire vs reality. In this case, the earlier
deployers of multiple algorithms are bearing the costs, and would expect to
gain the benefits of selective signature delivery slowly over time. Of
course they are imposing costs in terms of larger responses on everyone
else too, but they would be doing that even without this feature.

This feature is really looking longer term - and hoping to prepare us
better for the introduction of new algorithms in the future. If this gets
implemented, even if no-one initially uses it, we might be prepared for
future iterations of new algorithms (like various post quantum algorithms
or something else).


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

I was mainly disputing your remark about hoping there are no "weak"
algorithms :-)

I realize that keysize upgrade could address this, but so also could
rolling to a stronger algorithm like ECDPSAP256.


> 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.
>

You're only as strong as your weakest link. The weak link in almost all
deployed DNSSEC paths today is RSA1024. Your 2048-bit figure is for KSKs.
Most zone data is signed with RSA1024. Here are my current stats of TLD
keysize distribution:

Key Signing Keys (KSK):
1024 bits: 1 (0.0%)
1280 bits: 5 (0.2%)
1536 bits: 1 (0.0%)
2048 bits: 2022 (98.8%)
4096 bits: 17 (0.8%)

Zone Signing Keys (ZSK):
1024 bits: 1566 (69.7%)
1048 bits: 2 (0.1%)
1152 bits: 5 (0.2%)
1280 bits: 537 (23.9%)
2048 bits: 138 (6.1%)

So roughly 70% of TLDs sign zone data with RSA1024.


> 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.


Yes, I am in total agreement. We should as few strong ones as possible. But
that's still more than one.

Some crypto folks are now advocating for new protocols, define only one
cipher family and don't negotiate. But in reality, deployed protocols that
evolved over time have many, and correspondingly have a cipher negotiation
mechanism. TLS has something on the order of 100 cipher suites last time I
looked.

-- 
Shumon Huque.