[Freedombox-discuss] FOAF developers taking FreedomBox into their equation
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
>>> 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:
>> 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.
(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.
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
Social Web Architect