[dns-operations] Surprisingly large cluster of domains sharing the same pair of 512-bit ZSKs and some more RSA key oddities
Viktor Dukhovni
ietf-dane at dukhovni.org
Mon Oct 30 18:15:48 UTC 2017
> On Oct 30, 2017, at 10:36 AM, Petr Špaček <petr.spacek at nic.cz> wrote:
>
> I've asked people from CZ registry to relay the message. Hopefully Wedos
> will act on it.
Thanks, much appreciated. I also hope they will not the status quo
persist.
>> More broadly, the DNSKEY length (including exponent length and exponent)
>> histogram (distinct RR count) for keys for algorithms 5, 7, 8 and 10 (RSA)
>> is below, with some highlights annotated. It seems too many folks
>> stray into uncharted waters with their DNSKEY parameter choices. Perhaps
>> the key management tools should offer them less rope...
I think the lesson here, with 20/20 hindsight, is that it might have been
better to specify the RSA algorithm code points as having a fixed exponent
and fixed bit-length. It would have resulted in a few more RSA algorithm
ids, but would have reduced opportunities for exponent 3, too short 512-bit
or (IMHO much) too long 8192-bit keys.
I think that key generation utilities should, in the absence of some sort
of "force" option, refuse to unusual keys. At present that means:
* exponent is unconditionally 65535 (F_4)
* modulus length is a multiple of 8 bits
* 1024 <= modulus length <= 2048
The incentive for RSA moduli in DNSSEC above 2048 bits is at best weak,
because:
* The root zone KSK and ZSKs will not be stronger
* Ditto for signed TLDs
* DNSSEC keys are not long-term secret encryption keys,
they are traffic authentication signature keys. The
possibility of future compromise does not warrant
stronger keys in the present. We only need to defend
against today's capabilities.
To be fair, I don't recall any attacks on exponent 3 (or
other low exponents) that pertain to DNSSEC, since DNSSEC
is a signature-only system, and the data that is signed
is zone content, rather than random network traffic. So
perhaps e=3 is OK, but it is probably best avoided.
The statistics for TLDs are:
ZSK RRs:
flags | count | length (exponent length + exponent + key)
-------+-------+------------------------------------------
256 | 45 | 130 (1024-bit with exponent 3) [1]
256 | 1483 | 132 (1024-bit with F_4)
256 | 6 | 134 (1024-bit with exponent 2^32 + 1 = 641 * 6700417) [2]
256 | 3 | 135 (1048-bit with F_4)
256 | 5 | 148 (1152-bit with F_4)
256 | 531 | 164 (1280-bit with F_4)
256 | 156 | 260 (2048-bit with F_4)
256 | 1 | 516 (4096-bit with F_4)
KSK RRs:
flags | count | length (exponent length + exponent + key)
-------+-------+------------------------------------------
257 | 1 | 132 (1024-bit with F_4)
257 | 5 | 164 (1280-bit with F_4)
257 | 1 | 196 (1536-bit with F_4)
257 | 167 | 258 (2048-bit with exponent 3) [2]
257 | 1843 | 260 (2048-bit with F_4)
257 | 4 | 262 (2048-bit with exponent 2^32 + 1 = 641 * 6700417) [3]
257 | 16 | 516 (4096-bit with F_4)
[1] .com, .edu, .gov, .name, .net, .cc, .tv and various new gTLDs
[2] .ac, .io, .my, .sh and .tm
[3] .lv, .my and .pw
--
Viktor.
More information about the dns-operations
mailing list