7 ms·
Much better than (CA0 || CA1 || ... ). All it takes is one CA out of 10s of independent CAs to misbehave to insecure whole tls. In DNSSEC/DANE, world only has
by wav-part 8y ago
Much better than (CA0 || CA1 || ... ). All it takes is one CA out of 10s of independent CAs to misbehave to insecure whole tls.
In DNSSEC/DANE, world only has to watch one entity rather than 10s of entities.
- akerl_ 8y agoExcept if that one entity misbehaves, even if you catch them, you can't do anything about it, because they own the TLD.
- wav-part 8y agoYou have to trust somone under DNS. The only trustless naming system I can think of is over a PoWChain (eg example.btc). Still you have 3 choices in DNSSEC/DANE, - get a .xxx, trust dnsroot. - get a .xxx (when .xxx is as easy to register as xxx.com), trust dnsroot. - pick one tld out 1000s and get xxx.ttt, and trust ttt and dnsroot.
- akerl_ 8y agoI’ve got those choices if I use DNSSEC for my trust, correct. Or I use the existing system, where if a CA misbehaves, we boot them out of the browser trust stores and site operators don’t have to change anything.
- wav-part 8y agoExcept there has to be a crypto proof why Google owns google.com not me. That means we need to secure dns. Then why need CAs at all ? Whats the point ?
- tptacek 8y agoA group of certifying singers that aren’t directly controlled by the United States Government is the obvious reason.
- wav-part 8y agoCurrent: Google need to watch all CAs. DNSSEC: Google need to watch .com and dnsroot. Which one is better ? ---- (I am ratelimited so posting here rather than reply to the child post by tptacek https://news.ycombinator.com/item?id=18889809 https://news.ycombinator.com/item?id=18889809) Of course they can. There is literally no legal or otherwise difference between Verisign and .com. Chrome can do whatever it want, cause its Google's browser not .com's. In case when .xxx becomes dishonest, you can just move to your own gtld or .more-trustable tld. In current system, there is no concept of ditching a CA. If a CA decided to missmap a name and you are too small, you are fked. > it’s actually 1, or 1 AND 2 No you can have DNSSEC without CAs. I have explained that already without changing much of the tls. Basically example.com DNSSEC key become CA for example.com. example.com then would create a tls cert in the usual way. No pain.
- tptacek 8y agoThe former, for several reasons, among them the fact that those actually aren’t the options (it’s actually 1, or 1 AND 2), and the fact that Google can’t end .com they way they did Verisign. But feel free to ask the relevant team at Google, who will give you the same answer.
- akerl_ 8y ago“You can just move to your own <other TLD>” isn’t even remotely plausible. Any site with worthwhile traffic isn’t going to just forklift to a new TLD and convince all their users to switch over. Imagine if .com was considered untrustworthy and suddenly every user in the US had to use google.othertld, facebook.othertld, etc.
- topranks 8y agoYeah but if .com is untrustworthy then the game is up. The operator of .com can use their control over it to get a valid TLS cert issued by any number of CAs. So the situation is no different currently, trust in the DNS is essential.
- topranks 8y agoThe CAs, for the most part, only require you prove you control a domain to issue a cert for it. So you’re already trusting the DNS, whether protected with DNSSEC or not, in the existing system.
- tptacek 8y agoAnd yet when attackers want to misissue certs for small sites (for big sites, misissuance is detected automatically and gets CAs killed), they don't exploit vulnerabilities that DNSSEC defends against. Why is that? And given that's the case, why pursue DNSSEC? And how is any of this, any of it all, relevant in a world where registrars can simply speak RDAP to CAs? If you believe the problem is that the Internet will (to use your turn of phrase upthread) crumble away unless we secure the DNS for domain validation, why should we forklift out the entire DNS to do so, when we can just get a small group of organizations to deploy RDAP, something they're planning on deploying anyways, and then add that to the 10 Blessed Methods? No part of DNSSEC makes any sense.
- topranks 8y agoBecause the DNS as it is allows for the potential to do something similar (by getting a CA to accept fraudulent DNS response, leading them to issue a cert,) without someone seizing control of a domain otherwise. It makes no sense not to try to secure the DNS.
- tptacek 8y agoSecuring the DNS (a) doesn't fix the underlying problem for TLS (as you can see by the last 2 waves of CA-missuance takeover attacks, neither of which relied on wire-level DNS hijacking) and (b) adds nothing to any secure protocol, which already has to do end-to-end verification today. Despite that, DNSSEC is already the most expensive proposal we have on the table today, requiring every major site and every major piece of software to upgrade or reconfigure. Deploying RDAP and adding it to the CA/B Forum Blessed Methods gives CA's themselves an end-to-end ability to validate domains, decisively solving the DV problem, and doesn't require any of that expense. Explain to me again why we should choose the former over the latter?
- topranks 8y agoYeah but because they own the TLD they can get X.509 certs issued for any domain under it, because controlling the domain is the only check CAs really perform before issuing a cert for a domain. The DNS is already acting as the root of trust for X.509. X.509 does not make the scenario of a rogue TLD operator any different.
- tptacek 8y agoNo. You have to trust all the CAs, and the governments that control the DNS. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
- wav-part 8y ago> No. You have to trust all the CAs, and the governments that control the DNS. Not in DNSSEC. .xxx need only trust dnsroot. yyy.xxx need only trust .yyy and dnsroot. firefox/chrome/etc with support from important orgs with high value names (google.com/bankofamerica.com/etc) would then make sure that dnsroot/.com/etc do not abuse the trust. They have incentive and methods of punishment. There is no legal authority that clients need to map DNS . to existing root keys. A client can map a.b.c to any key it wants. The risk of gov overreach is same for both tls and DNSSEC. DNSSEC just trusts fewer entities. The only people who benefit from current system, are CAs who are getting $$$ for nothing. > https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html This is orthogonal. Weak Keys are not required or implied characterstic of DNSSEC.
- akerl_ 8y agoIf browsers start mapping cert trust to something besides the DNS roots... it’s not DNSSEC, it’s something else entirely, it’s “our current system, maybe with some slight tweaks”
- wav-part 8y agoI am not suggesting every client do their own mapping, that is not a naming system at all. There has to be very large consenus for a naming system to be effective. I just pointed that out to show that dns is not under any gov control. Its under a control of an entity that can be punished. However who gets to have dnsroot is just a value of a config in DNSSEC. The value itself should not be used to criticize DNSSEC cause its changeable.
- akerl_ 8y ago
- topranks 8y agoThere are about 1500 entities in the X.509 game, not 10s.