HN Explorer

26 comments

[ 4.8 ms ] story [ 73.7 ms ] thread
ryan-c
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.

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

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

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

cperciva 

    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?
ryan-c
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.
SmallDeadGuy
107 wrong and 6.2 million correct seems like a pretty low fraction to me.
jandrese
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.
userbinator
I wonder who are the two domains using such long keys:

     2 |   1028    (8192-bit keys)
wcarron
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.
bdonlan
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)).
tankenmate
Not to mention that on a slow resolver it might even trigger a time out and a SERVFAIL.
krisives
They are probably from Belize /s
phyzome
2048 was considered "long" not too long ago, and it isn't now. Perhaps someone is trying to stay ahead of the treadmill. :-)
feelin_googley
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.
DrPhish
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

feelin_googley
"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...

http://cr.yp.to/talks/2017.09.18/slides-djb-20170918-dnssec-... http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-... http://cr.yp.to/talks/2016.06.10/slides-djb-20160610-a4.pdf http://cr.yp.to/talks/2015.12.17/slides-djb-20151217-a4.pdf http://cr.yp.to/talks/2013.12.27/slides-djb-20131227-a4.pdf http://cr.yp.to/talks/2013.02.07/slides.pdf http://cr.yp.to/talks/2012.11.16/slides.pdf http://cr.yp.to/talks/2012.06.04/slides.pdf http://cr.yp.to/talks/2009.10.30/slides.pdf http://cr.yp.to/talks/2009.08.11/slides.pdf http://cr.yp.to/talks/2009.08.10/slides.pdf http://cr.yp.to/talks/2009.06.27/slides.pdf http://cr.yp.to/talks/2009.06.24/slides.pdf http://cr.yp.to/talks/2009.03.21/slides.pdf http://cr.yp.to/talks/2009.03.20/slides.pdf http://cr.yp.to/talks/2009.03.17/slides.pdf http://cr.yp.to/talks/2009.03.04/slides.pdf http://cr.yp.to/talks/2009.03.03/slides.pdf http://cr.yp.to/talks/2009.03.02/slides.pdf

A showcase of shard-db. Data from the Hacker News API. Refreshed every 15 minutes.

Source · Live DB stats