5 ms·

Good crypto for DNSSEC is available and is starting to gain traction: https://ed25519.nl https://ed25519.nl

tptacek 9y ago
Because of the architecture of DNSSEC, it's not in fact available until every DNSSEC resolver on the Internet supports it; until then, you have to keep bad crypto available, and expose users to downgrade attacks.
- xorcist 9y ago
  That is equally true of the global TLS PKI. Protocols are notoriously hard to upgrade, and endpoint policy upgrades perhaps more so than most.
  - tptacek 9y ago
    No, that's not true, and the way you know it's not true is that there's such a thing as a Qualys SSLLabs grade, where it makes sense to talk about individual systems being secured against specific cryptographic attacks. DNSSEC is all-or-nothing. You can publish Ed25519 records (in theory), but for anyone to talk to you, you'll have to publish equivalent RSA records --- more importantly, every parent zone also needs to publish secure records, or else your Ed25519 records are just theater. TLDs still have RSA-1024 keys! DNSSEC advocates really want DNSSEC's security to asymptotically approach that of TLS, but in fact DNSSEC is far worse.
    - xorcist 9y ago
      How is that not equivalent to TLS? The fact that you can talk about invididual domains and their key length should be evidence enough that Qualys, or anyone else, could do the same. You can get a ed25519 certificate for your web server today too, but hardly anyone would be able to communicate securely with you. Until deployment reaches critical mass you are in need of a fallback. Sunsetting protocols are even harder, so there's complete equivalency there. The use of TLS is just orders of magnitude more deployed than DNSSEC. There's also no need to suggest I am an advocate of something when stating basic facts about it. Real world systems are dependent on DNSSEC today, and nothing you or I believe will change that. I will not discuss specifics, but I am sure you recognize its use within well known public protocols such as SMTP and SSH.
      - tptacek 9y ago
        Because if I get a Qualys A+ configuration for my nginx, my CA can't make me vulnerable to BEAST. That's not true with the DNS.
        xorcist 9y ago
        How is BEAST relevant to any of this? It might be to some theoretical encrypted DNS, but not to the signature my CA provides to my certificate ownership just as it is not to the signature my registrar provides to my domain ownership.
        tptacek 9y ago
        Again: individual site owners can reliably enable modern curve crypto in TLS. Nobody can do that with DNSSEC; all DNSSEC crypto is lowest-common-denominator, where the lcd is 1024 bit or even 512(!) bit RSA.
        xorcist 9y ago
        I will refrain from begging you to answer the question. It is sufficient to note that every PKI is as secure as its weakest link. If my CA is 512 bit RSA, that is the security I am going to get. That public DNSSEC infrastructure is neglected in places is not really controversial or what we're discussing here, but the use of a singular trust root in place of hundreds should not be taken as evidence of incompetence from the protocol designer.
        tptacek 9y ago
        Please point to the 512 bit RSA CA that Chrome, Firefox, or Safari trusts.
        xorcist 9y ago
        Those are public web browsers and not really relevant to the matter here. They do not, as far as I know, implement DANE and if they did they would likely not trust 512-bit RSA certificates either. (Who knows? That might even have been a good way to bootstrap a good policy baseline, had they supported it.)

Because of the architecture of DNSSEC, it's not in fact available until every DNSSEC resolver on the Internet supports it; until then, you have to keep bad crypto available, and expose users to downgrade attacks.

xorcist 9y ago
That is equally true of the global TLS PKI. Protocols are notoriously hard to upgrade, and endpoint policy upgrades perhaps more so than most.
- tptacek 9y ago
  No, that's not true, and the way you know it's not true is that there's such a thing as a Qualys SSLLabs grade, where it makes sense to talk about individual systems being secured against specific cryptographic attacks. DNSSEC is all-or-nothing. You can publish Ed25519 records (in theory), but for anyone to talk to you, you'll have to publish equivalent RSA records --- more importantly, every parent zone also needs to publish secure records, or else your Ed25519 records are just theater. TLDs still have RSA-1024 keys! DNSSEC advocates really want DNSSEC's security to asymptotically approach that of TLS, but in fact DNSSEC is far worse.
  - xorcist 9y ago
    How is that not equivalent to TLS? The fact that you can talk about invididual domains and their key length should be evidence enough that Qualys, or anyone else, could do the same. You can get a ed25519 certificate for your web server today too, but hardly anyone would be able to communicate securely with you. Until deployment reaches critical mass you are in need of a fallback. Sunsetting protocols are even harder, so there's complete equivalency there. The use of TLS is just orders of magnitude more deployed than DNSSEC. There's also no need to suggest I am an advocate of something when stating basic facts about it. Real world systems are dependent on DNSSEC today, and nothing you or I believe will change that. I will not discuss specifics, but I am sure you recognize its use within well known public protocols such as SMTP and SSH.
    - tptacek 9y ago
      Because if I get a Qualys A+ configuration for my nginx, my CA can't make me vulnerable to BEAST. That's not true with the DNS.
      - xorcist 9y ago
        How is BEAST relevant to any of this? It might be to some theoretical encrypted DNS, but not to the signature my CA provides to my certificate ownership just as it is not to the signature my registrar provides to my domain ownership.
        tptacek 9y ago
        Again: individual site owners can reliably enable modern curve crypto in TLS. Nobody can do that with DNSSEC; all DNSSEC crypto is lowest-common-denominator, where the lcd is 1024 bit or even 512(!) bit RSA.
        xorcist 9y ago
        I will refrain from begging you to answer the question. It is sufficient to note that every PKI is as secure as its weakest link. If my CA is 512 bit RSA, that is the security I am going to get. That public DNSSEC infrastructure is neglected in places is not really controversial or what we're discussing here, but the use of a singular trust root in place of hundreds should not be taken as evidence of incompetence from the protocol designer.
        tptacek 9y ago
        Please point to the 512 bit RSA CA that Chrome, Firefox, or Safari trusts.
        xorcist 9y ago
        Those are public web browsers and not really relevant to the matter here. They do not, as far as I know, implement DANE and if they did they would likely not trust 512-bit RSA certificates either. (Who knows? That might even have been a good way to bootstrap a good policy baseline, had they supported it.)