Hacker News Reader

Comment by xorcist | Hacker News Reader

That is equally true of the global TLS PKI. Protocols are notoriously hard to upgrade, and endpoint policy upgrades perhaps more so than most.

View on HN

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.

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.

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.

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.

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.

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.

Please point to the 512 bit RSA CA that Chrome, Firefox, or Safari trusts.

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

I seriously don't understand what you're trying to say at this point.

The 512-bit RSA keys are a distraction. You're allowed to not care about the security of your own domain, but if your DNS hosting provider does not, and you do, get a better DNS hosting provider, all but two (of any size) use stronger keys.

ECDSA P-256 and P-384 are widely deployed. New algorithms will take some time to be widely supported by peer resolvers, just as TLS 1.3 will take time to be widely supported by web sites (browsers are more agile, but many websites still don't do forward-secrecy with TLS 1.2).

Algorithm agility is a thorny problem.

I agree that 512-bit keys are a distraction; the actual problem is the number of 1024-bit keys scattered throughout the DNSSEC PKI.

Algorithm agility is hard, but it's much harder in DNSSEC than it is in TLS.

Reply on news.ycombinator.com