On Fri, 24 Apr 2009, Joe Abley wrote:
What benefit is there of keeping the KSK small (e.g. 1024 bits) instead of
EDNS0 is a prerequisite for DNSSEC, if memory serves, so it's presumably not
TCP fallback we're worried about with larger DNSKEY RDATA.
I might run into some rally strange networks with my dnssec resolver on my
laptop. At least, the chance of broken strange networks is much higher
then the chance of receiving a notice that RSA 1024 can be broken within
one year.
(I am not advocating 1024bits for the KSK, I am just answering with a possible
benefit of keeping a small KSK)
only represents 384 more bytes of RDATA in a DNSKEY resource record on the
wire than a 1024 bit key, and 384 bytes doesn't sound (naively, no science)
like it's going to break the bank.
Is the root concern the computational expense of dealing with larger keys in
a validator? Or something else? Whatever the root concern is, what are the
boundaries?
It seems fruitless to debate whether 1024 bits is sufficient if there's no
real cost to just choosing (say) 4096 bits and avoiding the discussion.
I believe the main issue is packet size, not CPU power on the (stub) resolver.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
