> On Feb 26, 2021, at 1:06 PM, Bob Harold <[email protected]> wrote:
>
> If you sign your zone with several algorithms, and mark them all 'Strict",
> you are asking my resolver to do extra work. I will probably configure my
> resolver to only validate with one algorithm. Maybe the strongest, maybe the
> least cpu intensive, my choice, not yours.
In terms of downgrade resistance, that's just fine. The signal
should not be interpreted to require the resolver to check them
all, or any particular one. Rather, it would indicate that you're
free to conclude there's an attack and fail, if your preferred
strict algorithm is not included in the set of returned signatures.
This is sufficient to protect against downgrades from whatever
algorithm you would have chosen if you had them all, to some other
one that you would not have chosen.
One could also take the view that all the algorithms are equally
good, and ignore the signal, though if I saw a promise of P256 + RSA,
and got back just a 512-bit RSA signature, I'd be reluctant to
conclude that it is as strong as the missing P256 signature... :-)
So, in principle the proposal is a fairly natural anti-downgrade
mechanism. The main question is whether this is plausibly needed,
and here I am not so sure. I'd prefer to instead see more attention
to avoiding weak parameters.
This looking at SHA-1, we need to:
* Phase out DS hash algorithms 1 (and outdated GOST 3)
* Phase out DNSKEY algorithms 5 and 7.
Looking RSA-base DNSKEY algorithms, the the most widely used
RSA key sizes are:
# domains key bits
--------- --------
7,972,397 2048
7,342,144 1024
122,529 4096
22,678 1280
13,763 1536
8,273 512
1,502 Other [1]
I would therefore propose that we:
* Update the RSA-based algorithms to require keys of
at least 1024 bits and at most 2048 bits.
* After the sunset date, shorter keys are treated the
same way as unsupported algorithms (zone is unsigned).
* After the sunset date, longer keys are treated as
signature verification failure! For better security
than RSA-2048, use P256 or Ed25519.
* Set a sunset date for KSKs shorter than 1536 bits,
after which time KSKs with < 1536 bits are equivalent
to unsigned.
* Strongly recommend ZSKs of at least 1280 bits, and update
defaults in signing tools to be 1280 bits, if currently
set to 1024-bits.
* Recommend 1280 bits for ZSKs.
* Recommend 2048 bits or 1536 bits for KSKs
* Require the RSA exponent to be one of the 4
used in the wild that are not outright errors:
2^2^4 + 1 = 0x10001 = 65537 (8,126,993 domains)
2^2^30 + 3 = 0x40000003 = 1073741827 ( 29,398 domains)
2^2^0 + 1 = 3 ( 218 domains)
2^2^5 + 1 = 0x100000001 = 4294967297 ( 21 domains)
[ https://stats.dnssec-tools.org/ ]
possibly just the first 3, the 21 domains using 2^2^5+1 can
migrate to a more sensible exponent.
Improving practices in this space will do a lot more to improve
DNSSEC security than downgrade-resistant key algorithm signalling.
--
Viktor.
[1] Full RSA key bit size frequency table:
7972397 2048
7342144 1024
122529 4096
22678 1280
13763 1536
8273 512
345 1028
299 2304
268 2560
124 2024
114 1300
99 3072
72 2047
34 1023
22 1152
17 768
12 1350
12 1550
12 1048
10 2046
4 2014
4 2096
3 4086
3 2044
3 2045
3 1304
3 2112
3 1400
2 4095
1 1475
1 1483
1 1527
1 1530
1 1294
1 1972
1 1984
1 256
1 1292
1 2028
1 2038
1 2043
1 1291
1 1283
1 1248
1 1014
1 2119
1 1155
1 2319
1 2480
1 1080
1 1042
1 3096
1 3968
1 4075
1 4092
1 1336
1 1330
1 1345
1 1315
1 1430
1 1444
1 1455
1 1456
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
