On 06/09/2011 01:58 PM, Ewen McNeill wrote:
Hi Jay,
Hi Ewen,
On 2011-06-09 13:10 , Jay Daley wrote:
To recap and add some more detail, our explanation for choosing 1280 is: [....] 3. Recommendations by standards bodies in this area come into two categories[....] Using those guidelines, a key length of 1280 to *encrypt* something now can be conservatively expected to remain secure until 2014 and optimistically until 2017 (p26).
As an engineering observation, 2014 is _really_ close (approximately 24 months from deployment), and 2017 is still uncomfortably close. I understand that your usage method means that you might realistically believe that your safe usage time is longer than what you quoted (safer use case). But as a "worst case" engineering margin, "we'll be okay for at least a couple of years" is rather too close for comfort for me. (It looks very much like "we think that this is the minimum we can get away with".)
The intention of the policy (including the key sizes) is to be a live document. If at some point there is concern from NZRS or the community about the KSK length, the system is prepared to change the size of the keys fairly quickly. So we can start with a 1280-bit KSK and later increase the size of the key.
One need only look at, eg, research into MD5 weaknesses over the last few years to see how rapidly "probably safe for now" can become "oh dear, we need something else" in the cryptographic world with a single breakthrough. Thus the typical cryptographic design allows quite a lot of engineering margin.
4. We do not want to push the key size up to 2048 "just to be sure" because that imposes a greater DNS packet size and CPU cost for signature verification for end users of DNSSEC.
My (admittedly high level) understanding is that the KSK (public key portion and signatures) would typically be seen/transferred by DNS clients (recursive caches) relatively infrequently. As the KSK is used solely for signing ZSKs. ZSK signatures would be expected to appear on the wire all the time, and the size of those is reasonably a packet size consideration. But the ZSK public key itself, and the KSK signatures are surely only on the wire rarely, and thus their impact on the packets should be relatively insignificant.
The KSK is used to sign the key set (KSK + ZSK). The ZSK is used to sign the rest of the data in the zone. The query type for the key set is DNSKEY, which will be queried by a validating resolver once each TTL. Signatures travel together with the data, so in the case of a DNSKEY, the corresponding signatures go together. During normal operation, the key set will contain two keys (one KSK and one ZSK) plus one signature. During a ZSK rollover, an extra key will be present. During a KSK rollover, an extra key and extra signature. If we consider an emergency KSK and ZSK, during normal operation we will end up with 4 keys in the keyset.
Possibly I'm missing something here, but I had thought that DNSSEC was designed to avoid the "certificate chain bulk" of, eg, SSL/TLS/HTTPS for this reason.
FWIW, it's been a long time since 2048-bit crypto keys presented a significant workload to modern CPUs when verifying signatures. And I'd expect KSK signature verification to be sufficiently infrequent not to dominate CPU usage; ZSK signature verifications would be expected to happen "all the time", and thus a CPU concern.
I could, eg, see a 2048-bit KSK (rolled, eg, yearly) and a 1024-bit ZSK (rolled fairly frequently) as a reasonable engineering trade off. But I'm struggling to see a 1280-bit KSK as a reasonable choice in 2011.
Given that it appears someone has done some careful maths to determine that 1280-bits is the largest they're willing to recommend, perhaps you could explain how that translates into packet size boundaries that you're concerned about? (Eg, 512-byte UDP minimums? 1500-byte (ethernet) common packets?) And how frequently those packets are expected to be transferred (eg, every response, once per TTL, etc). Also it may help to speak to why, eg, 1536-bit wasn't being suggested if you wanted "smaller than 2048-bit" size.
We investigated different KSK sizes and their effect in response sizes for a DNSKEY query. The 512-byte limit was a concern before initial DNSSEC deployment, but the system seems to be coping well. The main concern is about clients supporting EDNS but being unable to receive fragmented packets. So we aimed to have a DNSKEY response below the 1420-bytes (Ethernet MTU - headers). The following table represents the size in bytes of a key of certain size as represented in the DNS packet: keysz rdlen 1024 136 1280 168 1408 184 1536 200 1664 216 1792 232 1920 248 2048 264 The following table represents the size in bytes of a RRSIG record created using a key of certain size: keysz rdlen 1280 187 1408 203 1536 219 1664 235 1792 251 1920 267 2048 278 With this data, you can play around different scenarios. Please note each DNS response has an overhead of aprox 100 bytes. That number is based on experimentation and was obtained as the difference between the response size and the sum of sizes of the keys/signatures in the response. Assuming a 1024-bit ZSK, we have: KSKSz # KSK #ZSK #RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 1 1 1 168 136 187 591 1408 1 1 1 184 136 203 623 1536 1 1 1 200 136 219 655 1664 1 1 1 216 136 235 687 1792 1 1 1 232 136 251 719 1920 1 1 1 248 136 267 751 2048 1 1 1 264 136 278 778 So far so good. During a ZSK rollover we get an additional ZSK KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 1 2 1 168 272 187 727 1408 1 2 1 184 272 203 759 1536 1 2 1 200 272 219 791 1664 1 2 1 216 272 235 823 1792 1 2 1 232 272 251 855 1920 1 2 1 248 272 267 887 2048 1 2 1 264 272 278 914 During a KSK rollover we have an additional KSK and RRSIG KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 2 1 2 336 136 374 946 1408 2 1 2 368 136 406 1010 1536 2 1 2 400 136 438 1074 1664 2 1 2 432 136 470 1138 1792 2 1 2 464 136 502 1202 1920 2 1 2 496 136 534 1266 2048 2 1 2 528 136 556 1320 The 2048-bit key is very close to the limit, but still good. What if the KSK and ZSK rollover happen at the same time. KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 2 2 2 336 272 374 1082 1408 2 2 2 368 272 406 1146 1536 2 2 2 400 272 438 1210 1664 2 2 2 432 272 470 1274 1792 2 2 2 464 272 502 1338 1920 2 2 2 496 272 534 1402 2048 2 2 2 528 272 556 1456 That doesn't look that bad. If we use an emergency KSK during a rollover, things get bigger KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 3 2 2 504 272 374 1250 1408 3 2 2 552 272 406 1330 1536 3 2 2 600 272 438 1410 1664 3 2 2 648 272 470 1490 1792 3 2 2 696 272 502 1570 1920 3 2 2 744 272 534 1650 2048 3 2 2 792 272 556 1720 The worst case: emergency KSK and ZSK during a KSK and ZSK rollover KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 3 3 2 504 408 374 1386 1408 3 3 2 552 408 406 1466 1536 3 3 2 600 408 438 1546 1664 3 3 2 648 408 470 1626 1792 3 3 2 696 408 502 1706 1920 3 3 2 744 408 534 1786 2048 3 3 2 792 408 556 1856 For this long list of tables and numbers, you can see the 1280-bit KSK is a good trade-off between key strength and flexibility to operate rollovers in a way that ensures the chain of trust is not broken.
We are also acutely aware that a TLD registry often sets a de facto standard followed by their registrars and registrants, which magnifies the impact of our choice.
Surely that's at least as strong an argument for taking the safe engineering approach, to avoid everyone else getting hooked on a "hopefully safe for 2-5 years, all going well" approach and immediately having to re-engineer things following a discovery that makes key cracking 10% easier.
Ewen
PS: I must say, for the record, that I find it extremely refreshing that their are NZRS staff who are both willing to have this discussion in public, and able to discuss the technical issues in detail. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Cheers, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535