And for anyone who's thinking TL;DR here's the summary from xkcd;

http://xkcd.com/538/

A security process is only as strong as it's weakest link and if you have a nice strong chain overall there's no point forging one particularly massive link somewhere along the way just because you happened to have surplus steel or you think it makes the chain look intimidating.

Is this a fair summary?

On 10 June 2011 02:55, <bmanning@vacation.karoshi.com> wrote:
On Thu, Jun 09, 2011 at 11:38:47PM +1200, Dean Pemberton wrote:
>
> There have been some well presented arguments for both 1280 and 2048 bit
> keys today.
> My initial query was to why 1280 keys had been chosen over 2048 bit
> keys, and that this seemed to be a departure from accepted practice.
> Both Sebastian and yourself have provided an enlightening discussion of
> the thought process behind this. �You've even pulled in the BigGuns(tm).

� � � �accepted practice is driven by vendor defaults and recomendations,
� � � �not always grounded in good practice. � e.g. �accepted != good.

> 1280 bit keys ARE less secure than 2048 bit keys, and as you point out,
> both of these are less secure than 4096 bit keys.

� � � �what do you mean by "secure"? �harder to break, with all other
� � � �factors being equal? �perhaps true. �-BUT- there is such a thing
� � � �as "overkill" ... do you really need a 8192bit key for a DHCP lease
� � � �lasting 15minutes? �I am not persuaded that the information moved
� � � �in that 15min interval needs a 20year protection window. �What was
� � � �missing in the presumptive key selection was the temporal lifespan
� � � �of the key. �As mentioned earlier, a 1280/1 key might be stronger
� � � �than a 2048/5 key.

> So I believe that there are two issues here...
>
> 1) Are 1280 bit keys secure ENOUGH for a 1Y rolled KSK?
> 2) Is having a bit length smaller than the majority of other DNSSEC TLDs
> going to be a problem for people trusting .nz

� � � �you really need to add a couple of queries.

1b) Are 2048 bit keys secure ENOUGH for a 5Y rolled KSK?

> My answer to 1 is "I can't be sure, opinions vary, but NZRS has
> consulted experts in this field and they seem to suggest that it a
> viable option at present."

My answer is .. Absolutly - given the current trend on crypto research and the fact
� � � �that we expect to change the material more often than a five year cycle.

> My answer to 2 is "I believe that people will view the .nz DNSSEC
> implmentation as less secure if it has a smaller bit-length KSK.
> Regardless of whether they are right or wrong, that will be the public
> perception."

� � � �Esp. when folks like you/me continue to trot out the mis-directed
� � � �presumption that size is the only thing that matters.

> What I do know for sure is, if you implement 2048 bit keys as you
> suggested in an earlier email, both of these questions are moot.
> Dean

� � � �Er, not really - then some wingnut is going to start harping on
� � � �4096bit keys. �The correct tactic is to understand the options for
� � � �the most robust security posture, not just bigger keys is better.
� � � �(which seemed to be part of the rest of this thread - a good discussion
� � � �btw)
/bill
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog