Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Because DNSSEC is just a second PKI that can't fix the problems with WebPKI without fixing those same problems with itself.

Oh, yes it can.

In DANE, say for example, if you have a .COM website, there is no chance that some obscure company from Russia, Turkey, China, or some other country out of hundreds, can issue a valid certificate for your website or any other TLS-based service that you're hosting.

In WebPKI that can happen at any time. Regardless of whether that would have subsequent repercussions... or not. Because maybe that company issued a certificate because they were attacked or exploited... say, for example, because some employee inserted a USB key on his computer (or got payed by a third party to do it).

So even when you are attacked in the WebPKI system, not only there's nothing you can do about it, but the CA that issued the certificate may not even suffer any consequences because of it (except having to implement "more security controls" or "fix some flaw", presumably).

And of course, each countries' national security agency can always bypass such security controls, as long as they can find some plausible cover story for the result of that CA's "investigation" of itself.



You're discussing a hypothetical world in which DANE was universally deployed and all Internet paths were clear for it. We can only asymptotically approach that world (and at present we are nowhere close). Until we get there, browsers have to be able to fall back to CA certificates. In addition to fallback being one of the most famous rats nets of security vulnerabilities in all of practical cryptography, this situation dictates that browsers won't be able to eliminate X.509 with DANE; they'll merely be adding a new trust anchor to the root store. The worst of both worlds.


> We can only asymptotically approach that world (and at present we are nowhere close).

Well, we're nowhere close because neither browsers nor operating systems are currently doing DNSSEC validation by default.

This could change (figuratively speaking) tomorrow if vendors decided to do so (along with implementing DNS-over-HTTPS if they haven't already).

> In addition to fallback being one of the most famous rats nets of security vulnerabilities in all of practical cryptography, this situation dictates that browsers won't be able to eliminate X.509 with DANE;

I think you are failing to see a future where the vast majority of these obstacles have been solved and therefore websites could afford to disable support for the remaining tiny (but long) tail of WebPKI-only clients.

Even despite the fallback problem, I think a DANE-based PKI system would be much simpler than WebPKI currently is, by orders of magnitude. So I don't think we would be worse than where we are now, where we just keep adding layers upon layers of complexity without actually solving the real problem at the root.

> they'll merely be adding a new trust anchor to the root store. The worst of both worlds.

No, it's not merely adding a new trust anchor, because that implies the old anchors would still be accepted even though the new anchor is working.

The idea is that if the client can do DNSSEC validation then it can disable all the other anchors and just use DANE (if the website has already migrated).


You are right. I am failing to see that future.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: