Re: [DNSOP] key lengths for DNSSEC

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Apr 2, 2014 at 11:19 AM, 🔒 Roy Arends <[e-mail]> wrote:

> On 02 Apr 2014, at 15:19, Jim Reid <[e-mail]> wrote:
>
> > There's been a lot of noise and very little signal in the recent
> discussion.
> >
> > It would be helpful if there was real data on this topic. Is an RSA key
> of N bits too "weak" or too "strong"? I don't know. Is N bits "good
> enough"? Probably. Change the algorithm and/or value of N to taste.
> >
> > My gut feel is large ZSKs are overkill because the signatures should be
> short-lived and the keys rotated frequently. Though the trade-offs here are
> unclear: is a 512-bit key that changes daily (say) better than a 2048-bit
> key that gets rotated once a week/month/whatever? Remember too we're not
> talking about keys to launch ICBMs or authenticate billion dollar
> transactions. I doubt it matters if a previous key can be cracked provided
> it gets retired before the bad guys can throw enough CPU-years to break it.
> >
> > However I'm just going on my own gut feel and common sense which could
> be wrong. Large keys might well be advisable at the root and/or for TLD
> KSKs. But so far there does not appear to have been much science or
> engineering on just how large those keys should be or how frequently they
> change. So in the absence of other firm foundations the established wisdom
> becomes "do what gets done for the root".
> >
> > If there is a threat or risk here, please present solid evidence. Or,
> better still, an actual example of how any DNSSEC key has been compromised
> and then used for a real-world (or proof of concept) spoofing attack.
> >
> >
> > BTW, the apparent profanity on an earlier thread was annoying because it
> didn't spell "whisky" correctly. As every drinker of fine single malt
> knows. :-)
>
> :-)
>
> Jim,
>
> Just a thought that occured to me. Crypto-maffia folk are looking for a
> minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia
> folk are looking for a maximum (i.e. at most soo many bits otherwise
> fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum
> might actually be larger than the DNS-maffia’s maximum.
>
> As an example (dns-op perspective).
>
> Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at
> least 768 bytes (and then some).
> Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at
> least 1280 bytes (and then some).
>
> Then there is this section in SAC63: "Interaction of Response Size and
> IPv6 Fragmentation”
>
> Which relates to response sizes larger than 1280 and IPv6 and blackhole
> effects.
>
> https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf


There is no doubt that we can get close to the limit on response sizes.
Which is why I have been pushing the notion that if we are going to do DNSE
then part of the DNSE solution should be to get us out of the single
response packet straightjacket.

Its not just crypto that gets crippled by this issue.

We are not in 1995 any more. We have bigger computing resources and bigger
security challenges. The Internet isn't a science project any more.


Too much of the debate here has been for one security approach versus
another. That is obsolete thinking we have been moving to multiple layers
of cryptography for some time now.



-- 
Website: http://hallambaker.com/