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

[Daniel Kahn Gillmor]

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?

> 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.

>> 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.

> 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.

> 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)

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?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110310/8186340d/attachment.pgp>