A Perspective on the KSK Rollover [Cybersecurity, Surveillance, Privacy]

[Farell FOLLY]

Thanks, Salanieta for sharing this.

Even if it might seem intuitive to always go for a higher key length, sometimes it does not improve anything including the performance, at least from a certain threshold. 

Firstly, the root server may have the required capacity to process all the requests, but not the tiny small device, which should also be able to afford the crypto algorithm complexity and key length too. 
Secondly, since signing a file involves transforming messages from a set M to hashes on a set H, from a certain point, increasing the key size without modifying the set H will not increase performance/efficiency because the collision domain remains unchanged (A collision is an event that occurs when two different messages produce the same hash or signature).
Thirdly, if a key of length K cannot be brute forced within a very very very long time (power of the human-being lifetime such as 2,000,000 years), it is unnecessary (but not useless) to increase it.

That said, Tomslin could you please share the ICANN document that says it is not necessary to increase the key size? Perhaps, they have different arguments.


@__f_f__

Best Regards
____________________________________

(Ekue) Farell FOLLY
NCUC Rep. to the NCSG Policy Committee
linkedin.com/in/farellf 






> On 16 Oct 2018, at 02:42, Tomslin Samme-Nlar <mesumbeslin at gmail.com> wrote:
> 
> Thanks for sharing Salanieta. 
> 
> A higher crypto key strength/size is indeed something ICANN should consider, since the root zone is well, the root! 
> I haven't read the report where RSPK found no compelling ground to increase the algorithm size of the key. I'll dig it up and see why they believe it is not necessary.
> 
> Cheers,
> Tomslin
> 
> On Mon., 15 Oct. 2018, 05:13 Salanieta Tamanikaiwaimaro, <sala at pasifikanexus.nu <mailto:sala at pasifikanexus.nu>> wrote:
> Dear All,
> 
> Here is an Article I posted yesterday, following the successful KSK Rollover on the 11th of October, 2018 and most of Oceania's 12th October, 2018.
> In it I raise issues concerning Surveillance, Privacy, Cyber Security and vulnerabilities of the Elliptical Curve Cryptography and I make a correlation with the Surveillance at the Telecommunications layer and wonder what is to stop this from happening in the Root Level.
> You can read the Article by clicking here <http://www.circleid.com/posts/20181013_ksk_rollover_elliptical_curve_vulnerabilities_surveillance/>. 
> As an additional note, you would think they would go with the highest size key strength available as it is the single point of failure for the entire DNSSEC system and single point of target as Todd Knarr points out.
> 
> Cell: +679 7656770; +679 7220149
> Tel: +679 3362003
> E: sala at pasifikanexus.nu <mailto:sala at pasifikanexus.nu>
> Website: www.pasifikanexus.nu <http://www.pasifikanexus.nu/> 
> Twitter: @SalanietaT
> 
> Please consider the environment before printing this email.
> 
>  
> 
> This transmission is intended only for the use of the addressee. It may contain confidential or legally privileged information. If you are not the intended recipient, KINDLY NOTE any use or dissemination of this communication is prohibited and no confidentiality rights or legal professional privilege are hereby waived. If you have received this transmission in error, please notify us immediately  and destroy and/or delete all hard and soft copy data relating to this transmission. The contents of this email, unless expressly stated, do not comprise the views of, or any representation by, Pasifika Nexus, directors or staff. Pasifika Nexus has active anti-virus and anti malware measures on its electronic mail system but cannot accept any liability for virus damage suffered by any recipient as a result of this or any transmission to that recipient.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20181016/20ad8a00/attachment.htm>