[Freedombox-discuss] Friendika

Henry Story henry.story at bblfish.net
Fri Jul 15 08:20:50 UTC 2011 

On 14 Jul 2011, at 20:50, Boaz wrote:
> [snip]
> Personally, I think that people overstate the advantages of WebID over
> password authentication for this use case by emphasizing that WebID
> frees people from thinking of and remembering passwords.  It only does
> that by having the browser think of key pairs and remember private
> keys, for the user.  If the user had to do this himself, it would be a
> much scarier nightmare than the password debacle.  Similarly, the
> browser could (and indeed Firefox has this feature) remember (and
> maybe even think of, I'm not sure if Firefox does this but anyhow it
> could) passwords on behalf of the user.  I mean, I do totally see the
> advantages (the linkable identity and so on), I just think that the
> "don't need to remember passwords" point is a bit overstated.

yes, Firefox weave is trying to automate the process of helping the
browser generate and remember every password for each site.

The difference of course with WebID is that there is no need to generate
a password for each site! For robots that need to communicate with each other
this is a huge improvement. Imagine a future web where we have 10s of thousands 
or 100s of thousands of sites our robots interact with for us. Suddenly they have
to generate and work with 100s of thousands of passwords, and the robots then 
have to synchronise that passwords too. With WebID your keys don't even have to be
synchronised!

> [snip]
> 
>> Your client certificate can be self signed without a problem of MITM. IT is the server lacking >a certificate signed by a trusted authority - CA or DNS or some friend - that would enable >MITM.
> 
> In the case of Alice and Bob, this distinction breaks down in a hurry,
> because both are going to need to play the role of client and server.
> Here's my story to demonstrate this: the two characters are meeting at
> a party.  After the party, Alice wants to read (privileged)
> information on Bob's web page.  How will she do this?
> 
> No problem, she'll sign in with a self-signed WebID.  Oh wait, how is
> Bob's web server going to know that some random person with a
> self-signed certificate should have access to privileged information?
> Oh I know, her WebID contains the url of her own home page.  Still,
> how does Bob's server know that this url is the url of someone Bob
> wants to be able to see this information?  Oh I know, she tells Bob
> the url of her homepage (which the short, easy to remember url,
> http://wonderland.net/foaf.rdf#alice_doe) at the party.

Well it could even be an e-mail with webfinger resolution. 


>  Fine, so then
> the self-signed client certificate that her browser presents Bob's web
> server references her homepage.  Bob's server fetches that page, which
> corroborates that the key is the right one.  Oh joy, now Bob's server
> can present this stranger privileged information.  Oh wait, that's no
> good; Mr Evil Man In the Middle Esq. will just present his own
> self-signed certificate to Bob's server, referencing Alice's homepage,
> and then when Bob's server turns around to fetch Alice's homepage, Mr
> Middle masquerades as wonderland.net and provides a page which lists
> his own key as Alice's.  Alice can't just act as a client.  She needs
> to act as a server, too.  And if we want anything to be at all secure
> about all this, she needs to be able to authenticate her server
> identity.

yes, which is currently best done using CA signed certificates on the server, 
in the future even better done with DNSsec and DANE, and an option to explore 
would be httpk.
http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html

>  And, as you say:
> 
>> The server certificates work much better when relying on a CA of course.  Without CA >signed certificates the client or the server would not know if they  have really reached the >server. So there is an attack that is possible there.
> 
>> IT is the server lacking a certificate signed by a trusted authority - CA or DNS or some friend >- that would enable MITM.
> 
>> If your web site had a self signed certificate then you would be no further than if you used >only http as far as security goes
> 
> Okay, so we have a problem here.  Someone has a conceptual notions of
> an “identity” for another person, something like, “that girl I met at
> that party”, and wants to share secret information with the person
> having that identity.  Now he is presented with a public key.  Is that
> public key held by the person with the identity he's concerned with?

The browsers is presented with the public key of the server signed by a
CA, in the future signed by DNSsec perhaps, or that key could be found 
IN DNSsec. That is how Bob knows he is connected to the right server. Because
he is connected to the right server he also knows that he has the
right profile page.

> So, while WebID is a great spec for how the girl he met at the party
> will sign into his website everyday  to access today's new round of
> secret information, it doesn't really address the question of how he
> can be assured that her WebID belongs to the person with the
> “identity” that he wants to share secret information with.

No you are getting confused because you are removing CAs from the picture.
You can do that, but then you need other systems to replace it. To keep
things simple to start, allow for the existence of CAs. They can be
improved on later.

Security like knowledge is modal.
http://blogs.oracle.com/bblfish/entry/the_fifth_dimension

> 
> This is the problem I refer to as “authentication”.  By
> “authenticating” a key, I mean receiving some strong assurance that
> that key is owned by the person with the “identity” who you think it
> is, that the corresponding private key for the public key:
> bf cb b8 10 20 d0 17 54 4c ab b9 49 5a a8 03 dc
> ad 74 a7 b3 26 49 48 7e eb 67 21 f9 f6 fe 70 30
> f3 f4 4e e6 47 f1 f7 a1 11 59 75 1e a0 0f c5 77
> f6 e4 dd dc 4b 9e 12 99 7b 5e f3 c4 10 97 73 fc
> 7f d0 64 ec 69 eb 62 08 ea 0e 04 c1 1f bf d3 19
> 52 fe aa 80 61 f8 40 9f 5b 96 ff ea d4 87 bc c9
> 5b 61 b6 c4 62 45 6b 66 f6 b1 20 8d e4 27 59 81
> ac 28 cd c7 d2 60 1c 0b fa 08 ce a3 85 d0 e5 3f
> is stored on a machine under the control of “that girl I met at the party”.
> 
> If we want the blessings of cryptography to shine upon humanity, we
> need to address this problem.
> 
> Let's address one solution which doesn't work:

You keep jumping between client and server certs. WebId works because we have a system
for server certification that is working enough to get the other piece going.  So here you
move back to client certificates.
> 
>> CA will never be able to do end user certification. It's way beyond them. They are already
>> struggling to certify paying businesses. Nobody would want CAs to start certifying individuals.
>> This is why nobody thought of using Client Certs for authentication.
> 
> I whole-heartedly agree.  Their cumbersome and inelegant solution
> doesn't scale to 7 billion users.  Even if it did, I spit on their
> solution.  The Electronic Frontier Foundation's SSL Observatory
> (https://www.eff.org/observatory), has found that about 650
> organizations control certificate authorities that the major web
> browsers trust.  Considering that I don't even trust any individual
> one of those 650 organizations not to misbehave, I'm not happy with a
> solution requiring people to trust all 650 of them not to misbehave.

agree. The problem is in engineering as in politics it helps if one can work
with what one has right now. The trick is to find a way to move from where
one is to where one wants to be by small valuable changes. After all we don't just
want to get there alone, but to bring billions of people with us.

> 
> A few days ago, I sent out an embarrassingly long post describing the
> system that I think would effectively solve this problem.  To attempt
> to interest you, the reader of this post, to spend the time to read my
> very long post from a few days ago, and to convey the main point of it
> should you decide not to, I offer the following summary of it:
> 
> Persistent keys, tied to individual people, are exchanged,
> authenticated, and used.  The authentication may occur before
> beginning to use the key, shortly after, or long after.  They key may
> be authenticated by any of the means by which it's possible to
> authenticate keys, and may be used for all of the purposes for which
> it's possible to use keys.
> 
> By “means by which it's possible to authenticate keys”, I'm referring
> to things like ZRTP's short authentication strings, OpenPGP's web of
> trust, OTR's socialist millionaire's protocol, or key fingerprints
> exchanged by QR code (each discussed briefly in the very long post).
> By “purposes for which it's possible to use keys”, I'm talking about
> things like email, IM, VoIP, micro blog posts, web pages, and so on.
> That's the doctrine I'm preaching: authentication method need not be
> tied to communication protocol.

Anyway, I am happy that you really like the httpk protocol sketch as you
mentioned in  follow-up email. I'll try to do an implementation in my spare 
time.

Ok, I'll sign off here, for a bit, otherwise I won't get these things done.
I recommend you try implementing webid, and develop some services that use it.
Staring simple we can then move on to more and more decentralised pieces.


Henry

> 
> 
> Boaz
> 
>> Hi,
>> 
>> I am lurking here from time to time. As the chair of http://webid.info/ I welcome people to >join
>> the W3C incubator group and help us tighten the spec by producing more implementations. >We are currently working on developing a simple declarative test suite for webid >implementations.
>> 
>> On 13 July, Melvin wrote
>> 
>>>>>> WebID uses SSL, but as far as I understand it doesn't rely in any CA. The
>>>>>> certificates can be self-signed and they will work the same.
>> yes, the client side certificates don't rely on a CA. Neither does the WebID in the X509 Cert >have to be an httpS URL: it could be an http webid, in which case you have the possibility of >man in the middle attacks - which is a problem with username/passwords and e-mail >authentication nowadays. Of course a Relying Party (to use OpenId lingo) that receives an >http WebID should take that into account, and reduce trust levels. For some services this >may be ok - well it seems to be ok for the 99.99% web at present!
>> 
>> The server certificates work much better when relying on a CA of course.  Without CA >signed certificates the client or the server would not know if they  have really reached the >server. So there is an attack that is possible there. If that is not an issue that could be >bypassed, especially in server to server configuration. Of course in that case each side >should understand that the level of security is lower. But not lower than when we connect to >http://google.com/ . (On the client side connecting to a server that is not CA enabled leads >to ugly UI issues though.)
>> 
>> Now I think it would be great if everything were behind https. Then when google gave us an >answer we would not be in danger of receiving a man in the middle corrupted answer, >sending us to some other fake page. Security itself is social. If Google is not secure than >most things we do are not secure. If other web sites are not secure then google is not >secure - cause Google's crawler's could be man-in-the-middled.
>> 
>> But we can't get everything behind https if we _need_ to rely on CAs, as they are a >bottleneck. DNS is not perfect but already a lot better. So people who want to help increase >security there, should look at the IETF DANE work.
>> 
>>    http://datatracker.ietf.org/wg/dane/charter/
>> 
>> Try to follow what is going on there and try to make sure that servers can put self signed >certs into DNSsec. Then push browsers to implement this. Chrome has an implementation >where you can put a certificate signed by your DNSSec on your https end point, which would >also work.
>> 
>> If you don't want to rely on DNS then I wrote up how to do that on this list
>> http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html
>> (if someone wants to play on developing httpk, let me know. I just need some help with >distibuted hash tables)
>> 
>> 
>>>>>> It uses the
>>>>>> private key installed in your PC (which might not be very convenient) and
>>>>>> checks if it belongs to the public key (which you have copied sometime before)
>>>>>> returned by the FOAF file. If they match, your friends server can be sure that
>>>>>> you are who you claim to be
>>>>>> ( http://www.w3.org/wiki/Foaf%2Bssl ). In this scheme it doesn't matter which
>>>>>> the CA is.
>> On 13 Jul 2011, at 19:54, Boaz wrote:
>>>> 
>>>> Let's be clear: self-signed certificates provide no protection against
>>>> MITM attack.
>> Your client certificate can be self signed without a problem of MITM. IT is the server lacking
>> a certificate signed by a trusted authority - CA or DNS or some friend - that would enable >MITM.
>> 
>>>> In other words, no assurance to your friends that you
>>>> "are who you claim to be" (unless you gave them your key fingerprint
>>>> on a slip of paper or something).  That assurance is the service that
>>>> we supposedly get from certificate authorities.
>> CA will never be able to do end user certification. It's way beyond them. They are already
>> struggling to certify paying businesses. Nobody would want CAs to start certifying individuals.
>> This is why nobody thought of using Client Certs for authentication. But with WebID you >don't need the CA for the
>> client cert part! So a major problem of client certificates has vanished.
>> 
>> Hope that helps. There is a short introduction video now on http://webid.info/
>> 
>> Henry
>> 
>> PS.
>> 
>> And for those who have time to spare, I put gave a presentation on "Philosophy and the >Social Web" and the first
>> philosophy and web conference last year in Paris. Though this is in English:
>> http://bblfish.net/tmp/2010/10/26/
>> 
>> 
>>>> 
>>>> 
>>>> Boaz
>>>> 
>>>> _______________________________________________
>>>> Freedombox-discuss mailing list
>>>> Freedombox-discuss at lists.alioth.debian.org
>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>> Social Web Architect
>> http://bblfish.net/
> 
>> On 13 Jul 2011, at 20:50, Boaz wrote:
>> 
>>>>>> You dont need to give your key on a slip of paper (you can if you want
>>>>>> of course), it's on your home page.
>>>>>> 
>>>>>> Hopefully your freedom box also hosts a web server too, preferably with https
>>>> 
>>>> Okay, so you have a home page, and on this home page is your key.  And
>>>> you know the home page is authentic, because it uses https, which is
>>>> protected using - using what now?  Oh, that's right, that same key.
>> If your web site had a self signed certificate then you would be no further than if you used >only http as far as security goes - which is what people have been doing in the past 15 >years... I suppose you'd be better off then just with http in order to avoid client error >messages. And if you have been happy with signing into sites using e-mail authentication >then you are not going to be loosing anything having an http WebID.
>> 
>> If you want your profile secured then it is currently easiest to use a CA to certify your Web >Server. There are free CAs out there that work btw. (see the http://webid.info/ wiki) But we >need to put pressure on Browsers to implement IETF Dane so that we no longer need to >rely on that either.
>> 
>> In any case this problem is going to be a problem with all services: without https you won't >know that you have reached the right server, be it your search engine, your identity provider, >or others...
>> 
>>>> This is all well and good, it just doesn't provide any protection
>>>> against a MITM attack.  If you're okay with that, this is a fine
>>>> arrangement.
>> The Relying party with WebID still TLS to get the client's certificate. CA signed ones make >currently for a better user experience with the browsers.
>> 
>> Henry
>> 
>>>> 
>>>> _______________________________________________
>>>> Freedombox-discuss mailing list
>>>> Freedombox-discuss at lists.alioth.debian.org
>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>> Social Web Architect
>> http://bblfish.net/
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss

Social Web Architect
http://bblfish.net/

More information about the Freedombox-discuss mailing list