On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson <o...@ogud.com> wrote: > Doing these big jumps is the wrong thing to do, increasing the key size > increases three things: > time to generate signatures > bits on the wire > verification time. > > I care more about verification time than bits on the wire (as I think that is > a red herring). > Signing time increase is a self inflicted wound so that is immaterial.
Agreed… Signing time is our problem to manage as a budgetary matter. Bits on
the wire seem too small, relative to the overall stream of traffic, to be of
any significance. But...
> sign verify sign/s verify/s
> rsa 1024 bits 0.000256s 0.000016s 3902.8 62233.2
> rsa 2048 bits 0.001722s 0.000053s 580.7 18852.8
> rsa 4096 bits 0.012506s 0.000199s 80.0 5016.8
…you think the difference between 53 uSec and 199 uSec is material for
end-users? Even if they have to traverse several levels of zones signed at
4096 bits?
There’s also the issue that we have to plan some time in advance for changes
like this, and by the time the change is actually in production, these times
will have dropped still further. So, I agree, incremental and continuous
upgrading of key-lengths is necessary to counter brute-force attacks, but I’m
not sure I want the granularity to be so fine that I’m rolling KSKs all the
time.
-Bill
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
