
Large cluster of domains sharing the same pair of 512bit ZSKs and RSA key oddities - pwtweet
https://lists.dns-oarc.net/pipermail/dns-operations/2017-October/016878.html
======
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).

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

[https://crypto.stackexchange.com/questions/8454/what-
securit...](https://crypto.stackexchange.com/questions/8454/what-security-
authorities-and-standards-reject-e-3-in-rsa-when-and-with-what) is very
informative.

~~~
dfox
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)

------
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?

~~~
jlgaddis
> _65337_

You mean 65535? :-)

~~~
_jal
Evil!

~~~
justinjlynn
!livE

------
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](https://ianix.com/pub/dnssec-
outages.html)

[http://web.archive.org/web/20000824181520/http://cr.yp.to/dj...](http://web.archive.org/web/20000824181520/http://cr.yp.to/djbdns/forgery.html)

[https://media.ccc.de/v/27c3-4295-en-
high_speed_high_security...](https://media.ccc.de/v/27c3-4295-en-
high_speed_high_security_cryptography)

[http://cr.yp.to/talks/2017.09.18/slides-
djb-20170918-dnssec-...](http://cr.yp.to/talks/2017.09.18/slides-
djb-20170918-dnssec-a4.pdf) [http://cr.yp.to/talks/2016.12.08/slides-
djb-20161208-dnssec-...](http://cr.yp.to/talks/2016.12.08/slides-
djb-20161208-dnssec-a4.pdf) [http://cr.yp.to/talks/2016.06.10/slides-
djb-20160610-a4.pdf](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/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.12.27/slides-
djb-20131227-a4.pdf)
[http://cr.yp.to/talks/2013.02.07/slides.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.11.16/slides.pdf)
[http://cr.yp.to/talks/2012.06.04/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.10.30/slides.pdf)
[http://cr.yp.to/talks/2009.08.11/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.08.10/slides.pdf)
[http://cr.yp.to/talks/2009.06.27/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.06.24/slides.pdf)
[http://cr.yp.to/talks/2009.03.21/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.20/slides.pdf)
[http://cr.yp.to/talks/2009.03.17/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.04/slides.pdf)
[http://cr.yp.to/talks/2009.03.03/slides.pdf](http://cr.yp.to/talks/2009.03.03/slides.pdf)
[http://cr.yp.to/talks/2009.03.02/slides.pdf](http://cr.yp.to/talks/2009.03.02/slides.pdf)
[http://cr.yp.to/talks/2008.09.22/slides.pdf](http://cr.yp.to/talks/2008.09.22/slides.pdf)
[http://cr.yp.to/talks/2008.08.22/slides.pdf](http://cr.yp.to/talks/2008.08.22/slides.pdf)
[http://cr.yp.to/talks/2007.03.20/slides.pdf](http://cr.yp.to/talks/2007.03.20/slides.pdf)
[http://cr.yp.to/talks/2007.02.02/slides.pdf](http://cr.yp.to/talks/2007.02.02/slides.pdf)
[http://cr.yp.to/talks/2006.10.17/slides.pdf](http://cr.yp.to/talks/2006.10.17/slides.pdf)
[http://cr.yp.to/talks/2006.08.28/slides.pdf](http://cr.yp.to/talks/2006.08.28/slides.pdf)
[http://cr.yp.to/talks/2004.04.28/slides.pdf](http://cr.yp.to/talks/2004.04.28/slides.pdf)
[http://cr.yp.to/talks/2003.03.18/slides.pdf](http://cr.yp.to/talks/2003.03.18/slides.pdf)
[http://cr.yp.to/talks/2003.02.11/slides.pdf](http://cr.yp.to/talks/2003.02.11/slides.pdf)

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

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

