6 ms·

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

151 points by pwtweet 9y ago

ryan-c 9y ago
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 9y ago
  > 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 9y ago
    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 9y ago
      Mostly no security implications. e=3 has some doubts. https://crypto.stackexchange.com/questions/8454/what-security-authorities-and-standards-reject-e-3-in-rsa-when-and-with-what https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.
      - dfox 9y ago
        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)
- xoa 9y ago
  >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.
- sowbug 9y ago
  Hartman's law of prescriptivist retaliation strikes again... and again. https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
- wereHamster 9y ago
  > 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 9y ago
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 9y ago
  > 65337 You mean 65535? :-)
  - _jal 9y ago
    Evil!
    - justinjlynn 9y ago
      !livE
  - deleted 9y ago
    [deleted]
- ryan-c 9y ago
  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.
- taspeotis 9y ago
  "About 1,490 results" https://www.google.com.au/search?q=65337+exponent https://www.google.com.au/search?q=65337+exponent Although mind that some results have 65537 in them, too.
- SmallDeadGuy 9y ago
  107 wrong and 6.2 million correct seems like a pretty low fraction to me.
  - jandrese 9y ago
userbinator 9y ago
I wonder who are the two domains using such long keys: 2 | 1028 (8192-bit keys)
- wcarron 9y ago
  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 9y ago
    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 9y ago
      Not to mention that on a slow resolver it might even trigger a time out and a SERVFAIL.
- krisives 9y ago
  They are probably from Belize /s
- phyzome 9y ago
  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 9y ago
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 9y ago
  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 9y ago
    "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/djbdns/forgery.html http://web.archive.org/web/20000824181520/http://cr.yp.to/dj... https://media.ccc.de/v/27c3-4295-en-high_speed_high_security_cryptography https://media.ccc.de/v/27c3-4295-en-high_speed_high_security... http://cr.yp.to/talks/2017.09.18/slides-djb-20170918-dnssec-a4.pdf http://cr.yp.to/talks/2017.09.18/slides-djb-20170918-dnssec-... http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-a4.pdf 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/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.

151 points by pwtweet 9y ago

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 9y ago
> 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 9y ago
  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 9y ago
    Mostly no security implications. e=3 has some doubts. https://crypto.stackexchange.com/questions/8454/what-security-authorities-and-standards-reject-e-3-in-rsa-when-and-with-what https://crypto.stackexchange.com/questions/8454/what-securit... is very informative.
    - dfox 9y ago
      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)
xoa 9y ago
>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.
sowbug 9y ago
Hartman's law of prescriptivist retaliation strikes again... and again. https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
wereHamster 9y ago
> 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 9y ago

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 9y ago
> 65337 You mean 65535? :-)
- _jal 9y ago
  Evil!
  - justinjlynn 9y ago
    !livE
- deleted 9y ago
  [deleted]
ryan-c 9y ago
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.
taspeotis 9y ago
"About 1,490 results" https://www.google.com.au/search?q=65337+exponent https://www.google.com.au/search?q=65337+exponent Although mind that some results have 65537 in them, too.
SmallDeadGuy 9y ago
107 wrong and 6.2 million correct seems like a pretty low fraction to me.
- jandrese 9y ago

userbinator 9y ago

I wonder who are the two domains using such long keys: 2 | 1028 (8192-bit keys)

wcarron 9y ago
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 9y ago
  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 9y ago
    Not to mention that on a slow resolver it might even trigger a time out and a SERVFAIL.
krisives 9y ago
They are probably from Belize /s
phyzome 9y ago
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 9y ago

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 9y ago
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 9y ago
  "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/djbdns/forgery.html http://web.archive.org/web/20000824181520/http://cr.yp.to/dj... https://media.ccc.de/v/27c3-4295-en-high_speed_high_security_cryptography https://media.ccc.de/v/27c3-4295-en-high_speed_high_security... http://cr.yp.to/talks/2017.09.18/slides-djb-20170918-dnssec-a4.pdf http://cr.yp.to/talks/2017.09.18/slides-djb-20170918-dnssec-... http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-a4.pdf 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/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.