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.
In DNSSEC/DANE, world only has to watch one entity rather than 10s of entities.
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
This is orthogonal. Weak Keys are not required or implied characterstic of DNSSEC.
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.
Again this is unavoidable in any system that need trust. Thats why I like PoW DNS.
Lets say .com gets mismanaged. Community is infurious. firefox/chrome/etc demands that . remap .com to new more trustable entity. If . does not. firefox/chrome/etc then remap . to new more trustable entity, because .com must be as trustable as ., because .com is that important. New . give back ownership of all tlds to their previous owners. Except for .com. .com goes to the more trustable entity as intended. New .com then does again similar import of all good xxx.com.
In this whole incident, no one loses the ownership of their names except for .com and possibly . .
Now no gov can touch *.com. Though its different for cctld. Those are owned by their respective govs. Same goes for gtld. But no one gets to mess with . .com .org .net.
Ultimately its about deciding who gets to own "x.y.z" string brand globally/contextlessly. World obviously need a single naming system. Either that or expect to have multiple owners to "google.com".
My suggestions are required otherwise why would someone build a global brand if ownership is not safe or guarnteed enough. Future is way more chaotic. Without crypto, a global naming system is not going to survive.
All you need to obtain valid TLS certs for any domain is to make a CA think you control the domain. So the CA’s trust in the DNS root is already functioning as the basis of X.509.
Tell me more about how the whole thing crumbles away? Because I'm pretty sure I'm typing into a TEXTAREA on the real HN, and not some facsimile a DNS hacker created to fool me. The Internet seems to be working fine without the government-run PKI you're saying we have to have.
In pure DANE you need only trust the DNS root.
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.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)
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.
But feel free to ask the relevant team at Google, who will give you the same answer.
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.
So you’re already trusting the DNS, whether protected with DNSSEC or not, in the existing system.
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.
It makes no sense not to try to secure the DNS.
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?
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.