Stand-by KSK for algorithm rollover
Hi folks, I noticed that no stand-by KSK is pre-published in 2017-ksk rollover, right? I put it due to the limitation of size of DNS response. Any other concerns on stand-by KSK in real production network? Now I’m planning to put a stand-by key in algorithm rollover in my lab test. Because I think ECDSA saves much space than RSA, so maybe it is time to consider Stand-by key for algorithm rollover. Is there any special consideration should be taken care for stand-by key in algorithm rollover. Thanks in advance. Best regards, Davey
On Apr 10, 2019, at 3:31 AM, Davey Song(宋林健) <ljsong@biigroup.cn> wrote:
I noticed that no stand-by KSK is pre-published in 2017-ksk rollover, right? I put it due to the limitation of size of DNS response. Any other concerns on stand-by KSK in real production network?
Besides the fact that publishing a secondary or future key gives a potential attacker that much longer to crack it? That is essentially the same as pre-publishing other keys, which has been discussed in some detail on this list.
On 4/10/2019 1:17 PM, Fred Baker wrote:
On Apr 10, 2019, at 3:31 AM, Davey Song(宋林健) <ljsong@biigroup.cn> wrote:
I noticed that no stand-by KSK is pre-published in 2017-ksk rollover, right? I put it due to the limitation of size of DNS response. Any other concerns on stand-by KSK in real production network? Besides the fact that publishing a secondary or future key gives a potential attacker that much longer to crack it? That is essentially the same as pre-publishing other keys, which has been discussed in some detail on this list.
Hi Fred - Discussed and basically debunked. (I'm still trying to figure out who introduced this argument in the first place - it's a really unusual claim). The current keys are 2048 bit RSA keys. To find the private key to be able to form a signature, you need to be able to factor the 2048 bit public key into two primes. Right now the current thinking is mostly either it will take a long time to do the factorization, or the scheme itself (not the key) will be broken (e.g. via quantum computing attacks on the math) and no 2048 bit RSA key will ever be viable again. There are some other attacks, but those are generally on the place or device in which the private key itself is stored (e.g. DPA, Mission Impossible style, etc). Next - if we're rolling the active key every year or so over to the stand by key, then you've got at most an additional year to crack the stand by key. E.g. call it a 2 year life span for the key from generation to revocation. If you know of an attack that can recover an RSA 2048 bit private key in two years - let me in on it. The viable attacks will mostly be on the active key and probably involve social engineering or hardware hacking and B&E. E.g. it's going to be a lot cheaper and more fulfilling to attempt to attack the active private key rather than the stand by public key. Basically - https://en.wikipedia.org/wiki/RSA_Factoring_Challenge is a reasonable indication of the problem set and risk. Given that conventional computing still hasn't factored 1024, I think we're good for a long while on 2048. Quantum may eventually change this. If it does, it could break the existing root and any other trust anchor of similar size roughly at the same time. Let me put it another way. RSA 2048 bit is used for managing key material used to move $$$$ around. Have we heard of any attacks where money was stolen due to being able to "crack" an RSA key? So no - that's really not a reason not to generate and publish a stand by public key. Preventing the stand-by private key from fate sharing with the active private key - that may be a reasonable argument (e.g. too costly/painful/unwieldy/insecure to secure them separately), but that's fixable. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
participants (3)
-
Davey Song(宋林健) -
Fred Baker -
Michael StJohns