[Freedombox-discuss] FOAF developers taking FreedomBox into their equation

[Henry Story]

On 10 Mar 2011, at 21:53, Daniel Kahn Gillmor wrote:

> On 03/10/2011 02:54 PM, Henry Story wrote:
>> On 10 Mar 2011, at 19:44, Daniel Kahn Gillmor wrote:
>>> My question is how B validates the backhaul link.  That is, how does B
>>> know that they are actually talking securely to C?
>> 
>> Currently it would use https with CAs (and later DANE currently being
>> developed at the IETF in DNSsec). That work very widely, and are already
>> a lot better than what most web sites use.
> 
> Are you saying that DANE works very widely?  Can you point me to some
> evidence of that?

No, obviously not that is why I wrote "and later DANE" and even put it between parenthesis.

> 
>> Now if you can develop other methods to verify a machine, then those could be used additionally too. 
>> 
>> Self signed server certs could be validated by a bunch of your friends, which could set up friend DNSsecs presumably. 
> 
> OK, but if we're setting up new ways to verify machines then we might as
> well make sure those ways can verify end-user certificates directly,
> right?  Otherwise, all WebID does is add an additional potential point
> of failure for our validation scheme.

Not sure. DNS is not a good protocol to put end user data in; the web is much better
for that.

> 
>>> If the backhaul link is unvalidated (therefore spoofable) then an
>>> imposter capable of such spoofing can successfully masquerade as A by
>>> generating and deploying a FOAF file that asserts the information the
>>> attacker needs for their "false A" cert to be accepted.  So i don't
>>> think that counts as "secure authentication".
>> 
>> No that would be a very weak deployment of WebID.
> 
> glad we agree on that :)
> 
>> Not quite. The server certificate is identifying a service joe.name:443 . 
>> You could put that name in the server certificate subject alternative name.
>> Then you could apply the same principle by looking up the service in the place
>> one does those lookups in: DNS. Of course DNS is itself insecure, so this
>> only works with DNSsec, and that is what this group is working on:
>> 
>>  http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/
>> 
>> Then the pieces are tied together. Now they are you might say centralised.
>> Though DNS is not that centralised either.
> 
> Yes, this is an approach that cuts out the CA cartel.  I like that,
> because i think the CA cartel as currently implemented is quite problematic.
> 
> But it makes DNS an even-more-valuable target for centralized control.
> 
> Unfortunately, DNS *is* currently centralized, and DNSSEC does nothing
> to address that centralization.  In DNSSEC, the entities who control the
> signing keys for each zone "above" your delegated zone have the ability
> to spoof your credentials or to cause a denial of service.

yes, I don't think there is a miracle solution. This one could be better than
what we have now, which is the same, except that DNS can be broken any moment and we rely on a distributed cartel.

> 
>> So we are currently resting on some existing and widely deployed infrastructure. 
>> But we do not require them. Perhaps  you can find some interesting
> things to
>> explore in the direction of RFC 5081 "Using OpenPGP Keys for  Transport Layer Security"
> 
> RFC 5081 has been superseded by RFC 6091 (i'm one of the authors of the
> newer version).  And yes, i do think something along these lines is a
> good way to address server authentication.  We could also use it to
> address client authentication directly.

A cool. I don't really know those well. But at least now I know someone who does :-)

I'd be interested in seeing how WebID can be tied into PGP. There is no reason it could not... I know one can put an e-mail into a PGP certificate. Can one put a URL there too? Like a Subject Alternative Name?

What is useful if you look at the FAQ is that WebID also allows you through the reference to build a much richer and changeable profile that you would ever want to put into a certificate. 

http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_this_improve_over_X.509_or_GPG_Certificates.3F

(I am not being fair to PGP there perhaps, but then I am waiting for feedback)

This allows others to link to you, and so create a web of trust - using the word 'web' here in the same way as it is used in World Wide Web.

Or are you just totally against URLs?

> 
>> WebID currently is about client authentication. Not really about server
>> authentication. Though because they are symmetric, the intuitions
>> developed in one place can be applied at the other.
> 
> I think i'd say it a bit differently:  WebID is about taking advantage
> of existing server authentication mechanisms to get client
> authentication mechanisms "for free". (actually, at the cost of
> introducing another point of failure, which is the FOAF web server C
> itself, which must be 'net-connected and operable for WebID to work)

You get other very valuable pieces: linked data being the most important. The success of the web tells you haw important hyper text was. Hyper data won't be different.

> 
> Unfortunately, i don't actually think our existing server authentication
> mechanisms are healthy ones; they need to be fixed if we want the
> network to be resistant to attack by powerful adversaries.
> 
> But if we're doing the work to fix server authentication, there's no
> reason it shouldn't apply to client authentication at the same time,
> without introducing the additional point of failure.  No?

Well if you have server authentication that makes you happy, then is there really a problem left with client auth being webid like? It's very powerful, and much  more flexible.



> 
> 	--dkg
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss

Social Web Architect
http://bblfish.net/