Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

[Joe Abley <[e-mail]>]

On 2014-01-14, at 18:04, George Michaelson <[e-mail]> wrote:

> If multiple independent entities sign, can't they elect to use shorter algorithms?
> 
> I know 'short can be spoofed' is out there, but since there are now n * <512> instead of 1 * 2048 is it not theoretically possible that at a cost of more complexity, it can be demonstrated that as long as 1) the sigs are all current 2) all the sig agree then the risk of n 512-bit signings is not necessarily worse than one 2048 or 4096 bit signing, for the specific need we have: proof of correctness. (n is unstated. 512 is a nonce. I have no idea what the sweet spot of keysize and number of keys would be.)

If you sign the DNSKEY RRSet with N KSKs of the same size as the single current KSK, then presumably the expected time for one of them to be factored is N times lower than the expected time to factor a single key, given the same compute resources being available for each key in all cases.

This suggests that if multiple KSKs are used, the keys need to be longer, not shorter, if the same degree of protection is desired.

I'm assuming that what we're talking about is this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSK0
. IN DNSKEY KSK1
. IN DNSKEY ...
. IN DNSKEY KSKn
. IN RRSIG DNSKEY KSK0
. IN RRSIG DNSKEY KSK1
. IN RRSIG DNSKEY ...
. IN RRSIG DNSKEY KSKn

(the size of which makes my hair stand on end) and not this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSKnew
. IN RRSIG DNSKEY KSK

where KSKnew is some combinatorial function of {KSK0, KSK1, ..., KSKn} since this second approach still requires a single KSKnew to be prepared in a single place in order to generate the RRSIG, which would presumably be a non-goal of de-centralising control of the keys.

> I am not a cryptographer and do not play one on TV

Me neither.


Joe