12 ms·

"And, to this day, the DNSSEC specification for securing the Internet's domain name system limits keys to a maximum of 1,024 bits." That is a factually incorre

"And, to this day, the DNSSEC specification for securing the Internet's domain name system limits keys to a maximum of 1,024 bits." That is a factually incorrect statement. Currently the ZSK protecting the root zone is using a 2,048 bit RSA key. There are also many TLDs that are protected by 2,048 keys. There is absolutely nothing in DNSSEC that limits key length to 1,024 bits.

jgrahamc 10y ago
Also DNSSEC doesn't have to use RSA: https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/ https://blog.cloudflare.com/a-deep-dive-into-dns-packet-size...
- tptacek 10y ago
  No, it's true, you get the choice between RSA and terrifying NIST ECDSA on the terrifying NIST P- curves.
  - linkregister 10y ago
    As someone who is an amateur at cryptography, are you being earnest or facetious about the terrifying nature of ECDSA?
    - tptacek 10y ago
      Both ECDSA and the P- curves are terrifying. Not because NIST backdoored either of them, but because they're both comically easy to fuck up. They are last-generation legacy elliptic curve operations. Cryptographers have moved on to significantly better, safer designs. It's 2016 and the vanguard of cryptographic modernity in DNSSEC is P-curve ECDSA --- if you use it, you're taking a risk that some deployed resolvers won't understand your zones. The breaking-change new crypto in DNSSEC is already obsolete.
  - loup-vaillant 10y ago
    There's still the 25519 curve, whose constants are highly constrained around reasonable criteria. DJB most probably haven't put any backdoor in those. Plus, as far as big number arithmetic goes, it's relatively easy to implement.
    - tptacek 10y ago
      25519 is great. But you can't use it in DNSSEC.
      - loup-vaillant 10y ago
        Oh, yeah, standards. I believe someone here said you said one shouldn't rely on DNSSEC anyway?
        tptacek 10y ago
        We're on a subthread about DNSSEC, not about curves.
        loup-vaillant 10y ago
        Oops, sorry.
      - AndyMcConachie 10y ago
        It is being worked on. https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update/?include_text=1 https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-al...
    - vabmit 10y ago
      I just want to point out that the P-curves need not have unique features that allow for more efficient computations during code breaking in order to be "weak" or "backdoored". Simply the fact that the curves are standardized may allow expedited code breaking. We saw this with POISON NUT/CORAL REEF (where specialized hardware (PIQ Blade), pre-computation work, and an otherwise fine small standardized set of primitives allowed for rapidly broken encryption).
SEJeff 10y ago
But DNSSEC is pretty much a false sense of security. See the copious and lengthy critiques on it from tptacek (here on HN) about it. However, this blog post (also from him) is a good start: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- microcolonel 10y ago
  Given that the body which holds the root zone keys is the same body which delegated the zones in the first place, seems like it is about the best you can get with DNS itself. If we didn't trust the root, then DNS would be pointless anyway since end users would need to be mailed a public key before they could get any records. I do agree that DANE is a horrible idea for exactly the reasons he lays out though. I would never trade in private CAs for a PKI owned by either the UN or the U.S. Government (although USG would have some obligation not to suppress my zone without a court order, as I am a citizen). The UN is enough of a joke that they appointed Saudi Arabia to serve on the Human Rights Council (granted that expires next year); This year the Philippines joined.
tptacek 10y ago
Did this change? As recently as a few weeks ago the root ZSK was 1024 bits.
- AndyMcConachie 10y ago
  http://www.circleid.com/posts/20160928_increasing_strength_of_zone_signing_key_for_the_root_zone_part_2/ http://www.circleid.com/posts/20160928_increasing_strength_o... Changed October 1, 2016. So yes very recent.

jgrahamc 10y ago

Also DNSSEC doesn't have to use RSA: https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/ https://blog.cloudflare.com/a-deep-dive-into-dns-packet-size...

tptacek 10y ago
No, it's true, you get the choice between RSA and terrifying NIST ECDSA on the terrifying NIST P- curves.
- linkregister 10y ago
  As someone who is an amateur at cryptography, are you being earnest or facetious about the terrifying nature of ECDSA?
  - tptacek 10y ago
    Both ECDSA and the P- curves are terrifying. Not because NIST backdoored either of them, but because they're both comically easy to fuck up. They are last-generation legacy elliptic curve operations. Cryptographers have moved on to significantly better, safer designs. It's 2016 and the vanguard of cryptographic modernity in DNSSEC is P-curve ECDSA --- if you use it, you're taking a risk that some deployed resolvers won't understand your zones. The breaking-change new crypto in DNSSEC is already obsolete.
- loup-vaillant 10y ago
  There's still the 25519 curve, whose constants are highly constrained around reasonable criteria. DJB most probably haven't put any backdoor in those. Plus, as far as big number arithmetic goes, it's relatively easy to implement.
  - tptacek 10y ago
    25519 is great. But you can't use it in DNSSEC.
    - loup-vaillant 10y ago
      Oh, yeah, standards. I believe someone here said you said one shouldn't rely on DNSSEC anyway?
      - tptacek 10y ago
        We're on a subthread about DNSSEC, not about curves.
        loup-vaillant 10y ago
        Oops, sorry.
    - AndyMcConachie 10y ago
      It is being worked on. https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update/?include_text=1 https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-al...
  - vabmit 10y ago
    I just want to point out that the P-curves need not have unique features that allow for more efficient computations during code breaking in order to be "weak" or "backdoored". Simply the fact that the curves are standardized may allow expedited code breaking. We saw this with POISON NUT/CORAL REEF (where specialized hardware (PIQ Blade), pre-computation work, and an otherwise fine small standardized set of primitives allowed for rapidly broken encryption).

SEJeff 10y ago

But DNSSEC is pretty much a false sense of security. See the copious and lengthy critiques on it from tptacek (here on HN) about it. However, this blog post (also from him) is a good start: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/

microcolonel 10y ago
Given that the body which holds the root zone keys is the same body which delegated the zones in the first place, seems like it is about the best you can get with DNS itself. If we didn't trust the root, then DNS would be pointless anyway since end users would need to be mailed a public key before they could get any records. I do agree that DANE is a horrible idea for exactly the reasons he lays out though. I would never trade in private CAs for a PKI owned by either the UN or the U.S. Government (although USG would have some obligation not to suppress my zone without a court order, as I am a citizen). The UN is enough of a joke that they appointed Saudi Arabia to serve on the Human Rights Council (granted that expires next year); This year the Philippines joined.

tptacek 10y ago

Did this change? As recently as a few weeks ago the root ZSK was 1024 bits.

AndyMcConachie 10y ago
http://www.circleid.com/posts/20160928_increasing_strength_of_zone_signing_key_for_the_root_zone_part_2/ http://www.circleid.com/posts/20160928_increasing_strength_o... Changed October 1, 2016. So yes very recent.