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

Fri Mar 11 10:22:05 UTC 2011

On Thu, Mar 10, 2011 at 11:38:34PM -0500, Daniel Kahn Gillmor wrote:
>On 03/10/2011 08:44 PM, Jonas Smedegaard wrote:
>> If e.g. Verisign is untrusted, then remove Verisign root certificates 
>> from your system and any website using that CA will no longer be 
>> trusted.  This should be true also for WebID.
>
>The problem with this approach is a nasty social problem, rooted in the 
>single-issuer specification of X.509 certificates:
>
> http://lair.fifthhorseman.net/~dkg/tls-centralization/
>
>In short: there is a system of perverse incentives that force people to 
>keep "trusting" the untrustworthy middlemen.  We need to change that.

I totally agree.  And I totally agree that WebID when applied to classic 
web usage do not escape the security flaws inherent in classic web - 
i.e. blind trust in certain large companies like Verisign.

I also totally agree that DNSSEC do not solve this, only shifts which 
essentially non-trustworthy entity must be blindly trusted for the whole 
structure to work.

*But* we are not (necessarily) talking "classic web usage" here, IMO.  
We have a trick at our hands called FreedomBox, which may help leverage 
if used carefully.

With "carefully" I mean that we should beware of inventing custom 
protocols unique to FreedomBox.  We really want to communicate equally 
with anyone using same technologies as us, independent of their system 
being "boxed" like ours or not.  And also we really do not want our 
boxes to stand out too much on the internet, as that would make it too 
easy for evil-doers to then treat special any communication originating 
at our type of communication devices (e.g. to hunt them down, or more 
elegantly to drastically lower the quality of service for such devices).

Therefore I find it preferrable if using existing protocols that work 
great for the whole internet, but if that fails we can pick technologies 
that work great when applied to machines under our control, even if same 
technologies do not work similarly great for others.

My impression is still that a) WebID is great for FreedomBox even if 
still a security hazard (albeit not worse than without it!) for others, 
and b) no alternative protocol exist providing similar features as WebID 
(i.e. user-friendly _and_ secure _and_ RESTful) while working great for 
everyone.

>> Might be that the user runs IE8 with horrible settings, but the 
>> FreedomBox wanting to verify a claimed WebID does not, so that should 
>> not matter to us, I believe.
>
>You're missing the step of what i called the "backhaul link" earlier. 
>If the fb is verifying a claimed webid by visiting its stored URI, then 
>it needs to verify that its pubkey matches the pubkey served by that 
>URI.  But to verify that it is legitimately reaching the URI, the FB 
>needs to validate the certificate of the web server hosting the FOAF 
>file.  This leads to either:
>
> (a) infinite recursion, in the case where the web server's cert itself 
>contains a WebID-style URI, or

It is only infinite if we allow it to be.  I suspect resolvers of 
classical (flawed!) hierarchical SSL/TLS chained certs also put a limit 
on the amount of intermediary certificates before reaching the root is 
allowed before giving up.

Similarly I imagine we can decide (despite the protocol itself having no 
such limit) to not _bother_ resolve trust chains longer that e.g. 3 
levels - or "hops" or "degrees" in some other lingo.

Translated into human relations: You claim that I owe you money 
indirectly.  The "protocol" in our hood may be that I must pay if you 
can prove the chain of meney exchange among peope in our hood - but 
still I may choose to refuse your claim if it takes you more than a 
minute to explain the story of the missing money to me - even if time 
was not part of our shared protocol.

> (b) some other certificate verification method, which Henry Story 
>points out is the standard X.509 cartel today, and may move to 
>DANE-style DNSSEC-backed key publication.  I don't think either of 
>these methods is acceptable, so that leaves us with:

This will be cool when it emerges, and we can shift to that.

Perhaps it is even usable today, similar to WebID (in my perception) 
being usable today: with the condition of one piece of the puzzle is in 
the handls of engineers (read: located on FreedomBoxes) so can be taught 
the protocol more strictly than is possible on the wider internet.

> (c) sort out a better, decentralized certificate verification method. 
>But if we're going to do that, then we've begged the question.  We 
>might as well use this hypothetical better certificate verification 
>method directly on the client-side certs in the first place.

I suspect Monkeysphere belong here.  Imagine that we provide a tool 
where non-technical internet users are offered boxes that do not trust 
government powers but instead trust a different external entity being 
"the world's largest cloud of geek-developed web-of-trust".  Sure, this 
can in principle be attacked by _very_ clever superpowers using enough 
agents infiltrating that web-of-trust, but is IMO better than telling 
our non-technical users to become technical because they must trust 
themselves, not us, and we can only tell them to go make keysigning 
parties and create PGP keys like we do.

>I'm sorry i'm not offering a specific solution right now.  I would be 
>happy if someone else came up with one, or if i got the time to work on 
>the approaches that i think are promising.

Don't be sorry - it is super cool how you seek weak points and seem to 
actually know these parts.

But could you be persuaded to play along with my game of assuming we 
have FreedomBoxes at our hands?  Not that we magically should trust 
anything thrown into our boxes, but that we can assume them to not have 
_some_ of the flaws inherent to the world at large, e.g. our boxes are 
*not* born with *any* root certificates! Each FreedomBox need to grow 
trust in e.g. Verisign the exact same way as ad-hoc (self-signed) and 
peer-managed (i.e. CAcert.org style) root certs do.

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110311/9e22d353/attachment.pgp>