Large cluster of domains sharing the same pair of 512bit ZSKs and RSA key oddities | Hacker News Reader

Large cluster of domains sharing the same pair of 512bit ZSKs and RSA key oddities

lists.dns-oarc.net

151 pointspwtweet25 comments

Just as an example of how easy* it is for even experts to screw these things up, Viktor's followup email suggests that tools should enforce parameters.

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.

> The value for public exponent F_4 is actually 65537 ...

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).

Note that choice of e has no security implications as no valid message can be smaller than length(n)/e. Picking prime speeds up key generation slightly (by eliminating values for which there is no d=e^-1 (mod n), which means that new n or e has to be generated), picking low hamming weight values speeds up public key operations (significantly).

Mostly no security implications. e=3 has some doubts.

https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.

My comment was meant to say "as long as no valid message", which was intended to imply that for OAEP and PSS it essentially does not matter and for simple padding schemes e has to be sufficiently large (ie. not 3)

>Just as an example of how hard it is for even experts to screw these things up,

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.

Hartman's law of prescriptivist retaliation strikes again... and again.

https://en.wikipedia.org/wiki/Muphry%27s_law

> Just as an example of how easy* it is for even experts to screw these things up

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)

What the hell? I can imagine the occasional person typing 65337 when they mean 65537, but 107 such records?

> 65337

You mean 65535? :-)

Evil!

!livE

In my scan of the alexa top 1m domains in Aug 2013, there were 10 domains using 65337 and 54 domains using 65535. I suspect someone wrote bad instructions.

"About 1,490 results" https://www.google.com.au/search?q=65337+exponent Although mind that some results have 65537 in them, too.

107 wrong and 6.2 million correct seems like a pretty low fraction to me.

A typo involving a wrongly doubled number next to a wrongly not doubled number in the interior of the number seems like a very human error. Seeing it happen in 0.0017% of the cases doesn't seem all that hard to believe. I've processed human input, nothing surprises me anymore.

This aligns with at least one person's predictions about the use of weak encryption and high margin for error of setting up and maintaining DNSSEC. He occasionally presents on the "DNS Security Mess" and has long highlighted this among DNSSEC's various flaws, with examples of the screw ups so far and their consequences.

Can you provide a name or a link?

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

"Can you provide a name or a link?"

https://ianix.com/pub/dnssec-outages.html

http://web.archive.org/web/20000824181520/http://cr.yp.to/dj...

https://media.ccc.de/v/27c3-4295-en-high_speed_high_security...

"Personal experience and insight would also be appreciated"

Personal experience:

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.

Insight:

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.

I wonder who are the two domains using such long keys:

     2 |   1028    (8192-bit keys)

I mean, why not? I run a few small sites and even I throw a 4096-bit key in there on 'em. It's not a burden.

It's a burden on the DNS resolver side. 4096- or 8196-bit key operations aren't exactly cheap - and the time taken for the public key operation grows superlinearly with the bit count (depending on the specific variant of the modpow algorithms in use, somewhere between O(b^1.585) to O(b^2)).

Not to mention that on a slow resolver it might even trigger a time out and a SERVFAIL.

They are probably from Belize /s

2048 was considered "long" not too long ago, and it isn't now. Perhaps someone is trying to stay ahead of the treadmill. :-)

Reply on news.ycombinator.com