I did some reading over the weekend on DNSSEC and an alternative proposal DnsCurve and my conclusion is that neither really allows us to trust a computer.
Problems with DNSSEC: - Currently planned to use RSA-1024 which is reaching end of life so it will be a mess when somebody factors the root key. It should be noted that DNSSEC supports changing encryption algorithms but these changes will have to be installed in each implementing device. - It sends a lot of data for a small request making it a ~100x DoS amplifier (If I can find a connection which allows me to send packets with a spoofed source IP, I can flush your box off of the internet.) - Companies don't want to give up the addresses of internal server names, address not found errors should not be able to be spoofed, and companies need to add and remove servers from their network, taken together will lead to complexity which is the enemy of security. - The root key will be held by the US Commerce Department, this will introduce friction with some governments. It's a bit of a non-point though since it will be factorable with a few graphics processors by the time DNSSEC is finished rolling out. - It is turning out to be very difficult to implement. - Has the backing of Verisign and a handful of governments. DNSSEC advantages: - Has the backing of Verisign and a handful of governments. - The idea of hierarchical signing of keys is attractive, it seems silly that a browser would not be storing valid keys and doesn't throw an exception when there are multiple valid keys to the same URL. Problems with DnsCurve: - You cannot be sure that a domain hasn't been tampered with by a DNS cache admin. Unfortunately this will not be true for DNSSEC either until it is implemented all the way down to the browser level. - Servers must have specific names because their public key is encoded in their name this also limits the key size. - It is just an extension of the existing DNS system, not a rethink of the design. DnsCurve advantages: - It is just an extension of the existing DNS system, not a rethink of the design. - Simplicity. It only sits next to an existing DNS system and encrypts it's traffic to and from the next one. This will be an advantage for DNS admins who don't want to learn a whole new system. - DnsCurve caches can communicate with legacy DNS servers and will detect DnsCurve support on the fly. - Can traverse badly configured firewalls which will be troublesome for DNSSEC. - Uses elliptic curve cryptography which is not likely to be broken unless and until quantum computing pans out. - Provides confidentiality for DNS communication to and from the local cache. Not very useful until we have better treatment of http connections. - Has the backing of D. J. Bernstein, the inventor of source port randomization as well as tcp syn cookies and the DNS server with the best security track record. He seems to know his stuff. My conclusion: DNSSEC is a great idea which should be part of SSL. However in the DNS system it gives a bank (which should have at least RSA-2048) the same security as a blog which honestly who cares if it's redirected, someone will eventually figure out and fix it. Signing of the root will have no effect until every website admin, every ISP, and every cable/dsl router changes over to DNSSEC, by then RSA-1024 will likely be a joke and since increasing the size of the modulus would increase the DoS amplification, the only sane answer will be to change encryption algorithms which will be almost as bad as doing the whole implementation over again (every website must reinstall, every ISP, every cable modem, every browser...) DnsCurve is a hack to keep things going another ten years and is written by a guy who is very good at writing such things (syn cookies). The encryption mechanism is theoretically very good although the implementation needs review by more crypto experts. It should be far easier to implement because under the hood it's plain old DNS. If we are trying to fix X509 then DNSSEC is a great idea and I am in favor of applying the idea to X509 (or X510), however if we are trying to fix DNS then I am in favor of DnsCurve because it looks like it can actually be implemented before the encryption algorithm is obsolete. If I was working on DNSSEC I would be looking very closely at elliptic curve and ask Bernstein for advice. Given the current path of DNSSEC it appears there will be a lot of humor to be found as the Commerce Department attempts to sign the root. I send this out to people who know more about it than me, so please correct me :) Caleb PS. You can get the benefits of DnsCurve now (for websites which support it) by setting your dns server to the ip addresses given at opendns.org Story Henry wrote: > Thanks a lot Dan for the feedback. It is very helpful for us to understand > where things are going on the DNS front, as this is a core technology we are > building on. > > Here is how I see the DNSSEC and the foaf+ssl stories converging. > > DNSSEC solves the DNS security problem in a delegated fashion. As you say it > is a bootstrapper. As it is deployed the trust we can have in domain names, > and hence in URLs will grow dramatically. Not only will we be sure that we > are talking to the right machine (ip address to be correct), but it will be > easier for people to deploy secure endpoints such as https. > > Foaf+SSL builds on that to create a web of trust for agents. > > It is worth considering the difference between foaf+ssl and PGP, since you > mention it below. > > PGP ties the identifier (an email address usually) to a public key. There > is not 1 PGP keyserver: there are many. These need to be synchronised > somehow, and can easily get out of date. If you feel like your private key > has fallen in the wrong hands, you need to notify all key servers. > Furthermore your PGP web of trust is completely public. People can 20 years > later look at the relations of who signed whose key to determine who knew > whom. And there is no way of removing a relationship. > > FOAF+SSL on the other hand ties a public key to a WebId (a URL), which is > tied to a machine via DNS and soon DNSSEC. The key server is the web, which > is based on the internet, which is based on DNS. So we get all the good > properties of DNS. If your private key is compromised, you just need to > update the information at your WebId, and remove the public key information > there. Updating the foaf+ssl key server is as easy as updating a web page - > and this is even more true now that the RDFa spec has been blessed by the > W3C. So one of my WebIds is http://bblfish.net/#hjs, which tied to a web page. > Secondly you can protect who can see the relations in your web of trust. > You could allow only friends to have access to your friend relations using > HTTP access control. If you discover that someone you thought was trustworthy > no longer is, you can just remove them from your Foaf profile. Again that is > as simple as editing a web page. (try hunting down all the people whose PGP > profile you signed :-) > > So FOAF+SSL gives us a web of trust but built on the most powerful naming > system (key server) in existence: the web. The web is built on DNS, which is > has 25 years of successful delegation, and with DNSSEC will give us another > century :-) > > Even better foaf+ssl uses X.509 which thanks to your work is going to end > up being secure. Even better we don't rely on the CA signing part of X.509 > which was used to 'secure' servers, and so we don't suffer from the race to > the bottom you describe so well in your talks. In any case CA's never really > attempted to certify people. That would have been practically and legally > infeasible. > > So it seems to me that FOAF+SSL and DNSSEC are perfectly complementary. Of > course we still have to prove our case, and we have work to do building a lot > more cool demos to show how it can work... This is what we are buisy doing > now. > > Thanks again for your very helpful feedback. > > Sincerely, > > Henry Story > > On 20 Mar 2010, at 23:17, Dan Kaminsky wrote: > >> My critiques against X.509 come down to the fact that it's just not a >> very good way to delegate trust. The roots are all equal and the >> constraints don't work reliably. >> >> DNS has 25 years of successful delegation. It has one root and it's >> constraint system is very well designed. DNSSEC simply inherits this, >> and adds crypto. >> >> There is a significant question for DNSSEC, which is what do we put in >> DNS now that we have a way to bootstrap trust? >> >> Certs? >> Cert fingerprints? >> Public keys? >> Public key fingerprints? >> >> There are arguments for each. I'm leaning towards cert fingerprints >> right now, but haven't entirely decided. DNS is not a high bandwidth >> channel, it's a bootstrapper. So that's a constraint. Keeping >> appcompat with existing X.509 architectures -- making DNSSEC an >> exclusionary 'uber-root' -- has serious value too. >> >> One thing I should make clear is I see value to the CA's. >> Specifically, EV is the only way I see to overlay a closed, branded >> namespace on top of DNS. This is a big deal. >> >> The thing I want to make clear is that I am not a big fan of >> distributed trust systems. I tend to see them unable to scale. I am >> however even less a fan of tightly centralized trust systems. The >> central provider doesn't even need to be malicious, just overburdened. >> PGP doesn't work, not with web of trust and not with keyservers whose >> records are constantly getting out of date. >> >> Delegation works well, but only if the root of the delegation is >> trustworthy. Well, the corollary to so many things breaking if DNS is >> hacked, is that we really, really invest a lot of trust in the root >> already. You guys know the old quote, a CA is only as strong as the >> money it refuses to take? >> >> The root, as an element of be state system, is an element of the >> system that makes money itself. It's bureaucratic as all get out and >> this is not a bug, but a feature. Its intransigence is a useful >> defensive bulwark with no peer. >> >> >> >> >> On Mar 20, 2010, at 2:44 PM, Henry Story <[email protected]> wrote: >> >>> Hi, >>> >>> Here are two issues with X509 that were hindrances for a solution >>> like foaf+ssl to be deployed, but which can and are being fixed: >>> >>> 1. Client Side Certificate selection >>> ------------------------------------ >>> >>> Browsers currently do a very bad job of allowing the user to choose >>> his certificate (Safari being the absolute worse). As a result I >>> posted "Firefox Hackers Needed" >>> >>> http://bit.ly/cQ5f48 >>> >>> earlier this week. @snej who is working at Google put up a picture >>> of a solution for this in Chrome using a foaf+ssl certificate >>> created by http://webid.myxwiki.org/ >>> >>> http://bit.ly/azCXTU >>> >>> Vote for it! >>> >>> 2. Server side certificates >>> --------------------------- >>> >>> One factor that people mention often with foaf+ssl is that the >>> server has to have his own certificate. This means registration with >>> a CA which is costly and tedious and it does not really solve the >>> problems of server authentication as Dan Kaminsky shows ruthlessly >>> in "Black Ops of PKI" http://bit.ly/4Uwb2K . >>> >>> To summarise his talk, server security is in a double bind: >>> >>> 1- Dan Kaminsky's DNS poisoning attack which is very well explained >>> by Rick Van Rein's presentation "Cracking Internet: the urgency of >>> DNSSEC" ( http://bit.ly/2darr8 view with FFox > 3.5 as it uses ogg >>> video) means that a DNS easily be hacked in 6 weeks, and a lot of >>> money poured into the wrong people's pockets. So there is a >>> financial incentive to break DNS. >>> >>> 2. The solution of using https with X.509 public key cryptography's >>> backing cannot work because there is a race to the bottom in the way >>> CA's issue certificates. For enough money it is not that difficult >>> to become God and to pretend you are anyone. >>> >>> Given the above DNSsec has become urgent enough, that it is being >>> deployed. >>> >>> - verisign will put .com in July http://bit.ly/dyd54E >>> - .org will be available in June http://bit.ly/abEJ28 >>> - .gov went dnssec in March 2009 http://bit.ly/bH27b0 >>> - The root will be signed July 2010 http://bit.ly/9YQMDJ >>> - a map of dnssec deployment http://www.xelerance.com/dnssec/ >>> >>> So listening to Dan Kaminsky you would think that he is against >>> X509. Well certainly it could be improved a lot, but he is not quite >>> as negative as one may think. X.509 with DNSsec seems to be >>> something he thinks can work. >>> >>> What he told me after his CCC and HAR talks and what you can see in >>> the last few minutes of the HAR talk "X509 considered Harmful" >>> http://bit.ly/2darr8 >>> is that once DNS is secure one could put the X509 (self signed >>> even) certs into the DNS records. This would bypass the need for >>> CAs. [ I hope I understood him correctly ]. I am not sure what needs >>> to be done to make this possible with the browser vendors, but it >>> would massively improve security on the web. >>> >>> As a result I have fait that the global situation on the internet >>> will only make foaf+ssl solutions easier and more secure to deploy, >>> enabling a completely distributed social network to emerge, free and >>> without the spying, as Eben Moglen author of the GPL said so well >>> recently http://bit.ly/brQmJz >>> >>> Henry >>> >>> >>> Social Web Architect >>> http://bblfish.net/ > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
