Tent 0.4 notes

[danielsiders]

We plan for 0.4 to include:

• Streaming
• Groups (advanced features)
• a PGP-based Web of Trust

Development on the reference implementation and technical notes won't happen for at least a month, but now's the time to offer comments.

[titanous]

Streaming will be via Server-Sent Events.

Groups are used for permissions and will support referencing groups published by other entities.

[tjreo]

I've been thinking about Groups and have been using Instant Messaging as a way to think through how they could work. In IM, groups are used to keep messages within the group. In fact, the idea of a public post does not exist since messages must be addressed to one or more people.

1. What will/should happen to auth on existing posts when people are added to and removed from the group? My Guess: Granting will be easy. Revoking will be difficult if not impossible to ensure.
2. Where does the group live and who owns it? Does one entity own it? Does the group definition exist on each members Tent server?
3. Can we set fine-grained controls on who can manage the group? (Only owner can manage, Everyone can manage, Certain group members can manage)

[danielsiders]

@tjreo

1. Anyone in any group with permissions to see a post can fetch it until they are removed from the group or the group is removed from the post's permissions. No revocation (delete post) is sent out when a member is removed. Revoking access is easy and fast, "revoking" (asking another user to delete content) is technically unenforceable throughout Tent.
2. A group is just a Tent post. It lives on the server of the entity who created it. That user "owns" the group. No notification is sent to members if the group is not public (you don't know you're in a group someone else made if the group isn't public. In Tent v0.4 users can set the permissions on their post to include a group created/owned by another entity (the CEO of a company can manage a list of current employees and all employees can use that group as the permissions for all internal documents at a company. When the CEO changes the group membership, the updated version is sent to all subscribers [employees] and their servers alter post permissions accordingly).
3. Group posts work like all other Tent posts: only the entity who created it can edit or delete it. Of course you can write applications that enable complex multi-entity management, but at the protocol and server level only the creator controls it (e.g. User A creates a group and exposes it via a group management app to user B. User B sends a post via the group management app asking that an entity be added to the group. User A's copy of the management app receives the post from User B and modifies the group post accordingly. At the protocol level there's still just User A who created and controls a group on her server).

[poweruser82]

I still want static groups as in #184

[tjreo]

@danielsiders Slightly related. Are there apps that you believe should be bundled with (part of) a Tent server? You mentioned a group management app. It seems pretty foundational yet it is probably at a higher level in the technology stack than the Tent server.

[tjreo]

For PGP, will keys be stored as Tent posts or are they more deeply tied to the server?

[danielsiders]

@tjreo I won't speculate on the features that should be part of admin apps (which I think is what we're really talking about, app bundling is about content creation rather than admin utilities) until the app ecosystem is more robust. Without a wide variety of apps, we won't know what the standard experience will be and therefore what kind of utilities are generally needed.

We're still working out which parts of PGP will be exposed in what ways, need to poke around at some of the intricacies in the RFC.

[danielsiders]

@poweruser82 I just reread #184. I don't think you've made a case for this. Please provide clear use cases where dynamic groups would cause problems or static groups would create new possibilities.

Groups are permissions. Not being able to dynamically modify permissions means needing to delete entire posts to remove a user's access. That means lots of broken links and a huge burden on apps for housecleaning.

[seanmonstar]

Couldn't apps implement static groups by exploding the group and adding every entity explicitly to the permissions property?

[danielsiders]

@seanmonstar absolutely. from #184 : "It's trivial for an app to hardcode permissions by adding all members of a group to a post's permissions when that behavior would be desirable. Otherwise, dynamic permissions are the norm"

[poweruser82]

@danielsiders @seanmonstar I updated #184

[titanous]

Tent Signatures

Tent v0.4 uses the Ed25519 elliptic-curve public-key signature algorithm to sign posts. Each entity has a keypair generated and stored by the server. Posts are signed automatically by the server (using the canonical JSON). The public key is stored in a "key post". This post may be mentioned by other entities by signed "trust posts" in order to pin keys and create a web of trust.

Keys may be revoked by creating a new key post and updating the previous one with a revoked flag. All legitimate posts must be re-signed after a key change, with the exception of previously revoked key posts (these must be signed with the revoked key).

Servers must reject posts with invalid and revoked signatures. Servers may reject posts with no signature.

An endpoint is added that provides channel binding to TLS. This endpoint signs the server's current TLS certificate with the entity's signing key. The endpoint provides a lightweight, decentralized alternative to the X.509 certificate authority model by leveraging the Tent web of trust.

[tjreo]

Thank you for the update. What I'd love to see is a picture that shows all of the moving parts.

Are we saying that all posts (not sure what legitimate means in this context) must be resigned once a new key is derived?

[titanous]

@tjreo "legitimate" means not forged (if it was revoked because it was compromised). All posts must be re-signed with the new key after the old one is revoked. This can happen totally asynchronously (even lazily on read).

[danielsiders]

We're still working out the specific mechanic for flagging posts as unauthorized (besides revoking the key and deleting any unauthorized posts).

I'm also very interested in thoughts on what the defined "trust levels" should be. PGP uses a single axis. On the modern internet does it make sense to separate persona from physical world identity? e.g. I've met this entity in person and corroborated their key vs used out of band digital verification?

[iangreenleaf]

The web of trust idea is fantastic. Do you plan for this to interact with PGP keys at all, or is it a completely separate web? It'd be a bit of a shame to have two distinct trust webs that can't verify each other.

I'm also very interested in thoughts on what the defined "trust levels" should be. PGP uses a single axis. On the modern internet does it make sense to separate persona from physical world identity? e.g. I've met this entity in person and corroborated their key vs used out of band digital verification?

This is a great question. I've always thought that the identity we want to verify isn't so much what's on your birth certificate, it's that you are the same person with whom we have an established history of interaction. In meatspace, we conflate the two and it mostly works thanks to societal customs, but online it hardly matters if you're using your real name or a pseudonym.

That said, I don't know if a second axis is needed. It would certainly be more complicated. Could be that the Unverified/Casual/Careful system would still work fine, especially if it's rebranded to something like:

1. Don't know this person well
2. Short history of interaction
3. Know this person well / long history of interaction

[danielsiders]

@iangreenleaf it'll be separate from PGP--most of what PGP specifies isn't applicable to Tent. Tent also allows users to control the permissions on their endorsements of other users keys, PGP expects them all to be public and uploaded to servers. However you could sign your Tent key with your PGP key so PGP users can verify you're the same person.

[redaktor]

How do you think about guardians' Bruce Schneiers' note 5 : http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance "Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can." and http://grahamcluley.com/2013/09/nsa-cheated-cryptography/ ?

[titanous]

@redaktor Public-key crypto is required for cryptographic signatures. We are not using the NIST/NSA ECC spec, we're using a completely independently developed algorithm with nothing up my sleeve constants generated by a completely independent entity (D. J. Bernstein).

[redaktor]

:+1: