[Social-discuss] Re: [foaf-protocols] DNSSEC update and client side certificates

[Story Henry]

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 <address@hidden> 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/