One of his suggestions:
> exponent is unconditionally 65535 (F_4)
The value for public exponent F_4 is actually 65537 (a low hamming weight prime), not 65535.
* This comment originally read "hard" instead of "easy", which I totally did on purpose as a joke but fixed because it was confusing.
I assume you meant "...of how easy it is..."? Or was that itself a nice subtle example of the point? Either way it's certainly important to recognize how critical multiple review, as much automated checking (and even full formal verification in some places) as feasible, and so forth is for security. Really, it's just not a very human-firendly area full stop. The details really, really matter.
Though none of that means the experts aren't still better, relatively, then the rest of us, or that thoroughly tested and hardened code isn't better then DYI. It's just hard for everyone, and even higher level devs or operators still have to be careful of gotchas.
That's what I thought when I was reading the second post in the thread. I'm certainly no crypto expert, though, so I was left wondering why 65535 was being recommended when, for example, TLS often uses 65537. I was heading for the DNSSEC RFCs in search of an explanation when I decided to click over to the discussion thread and saw your comment so thank you for the clarification!
EDIT: I'm subscribed to this list so I just posted a "correction" (which is apparently pending moderation, for some reason).
https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.
You can't refer to everyone working in IT as an expert. We must have higher standards than just "Can you use Excel? Great, now go set up DNSSEC", which is what probably happened in this case of a generic hosting provider.
RR count | length
107 | 131 (1024-bit with exponent 65337 == 3*29*751)
You mean 65535? :-)
I just set up DNSSEC on my personal domains yesterday (got the DS records published), and would like to know what kind of pain I am potentially in for.
Personal experience and insight would also be appreciated
"Personal experience and insight would also be appreciated"
I never learned how to set up DNSSEC. It was a moving target at the time I became interested in DNS and as we know it has never been easy to set up. I did learn how to set up DNSCurve though.
I have no great insight. Around 2008 when the BIND "experts" acknowledged the problems with forgery and started pushing DNSSEC again, I stopped using shared caches. I switched to local dnscache only. Hence I see never had any need for DNSSEC.
Today I do not even use a local cache. I only use /etc/hosts and local authoritative servers, tinydns and nsd. This is mainly for speed and availability. To gather DNS data, I created a "nonrecursive resolver". It beats the speed of a cold cache.
2 | 1028 (8192-bit keys)