Re: [Sks-devel] Requesting your thoughts on a web of trust scheme

[Daniel F]

On Sat, Dec 10, 2011 at 8:52 AM, Arnold <address@hidden> wrote:
>
> In other words, the proposal suggests to make use of resources donated by
> the community for one cause, *to save investments* in realising a different
> cause, without asking our permission. This by itself is a very bad thing
> IMHO. (The question of Daniel F was about comments on the scheme, not about
> permission to use our network.)

Sorry if that wasn't patently clear, but a major component of posting
this on sks-devel rather than elsewhere was to ask for community
feedback, in effect 'asking permission'. Though you don't know me
personally, y'all can rest assured that I will not foist this on
existing SKS keyservers if the community objects.

In subsequent discussion with 'cj' on IRC, we have pretty much come to
the conclusion that it would be better for all if we stay away from
the existing SKS infrastructure and instead spin up a few of our own
SKS keyservers, modified not to talk to the existing network, thus
keeping the trading-trust data out of the existing SKS space.

On Fri, Dec 9, 2011 at 12:36 AM, Daniel Kahn Gillmor
<address@hidden> wrote:
> I'm not sure this is OT on sks-devel, unfortunately, so it'll be my last
> post on-list on this thread.  Some comments below.  Suggestions for a
> better place for further discussion are welcome.

Thank you for your comments all the same. Though I think this was
relatively topical, since the idea was to use the SKS keyservers :)

> I see two main ways the proposal could use improvement as presented:
>
>  0) increase clarity and precision of critical terminology, and

true, this was written in a more informal fashion, with certain
assumptions of context on the part of the reader (namely, bitcoin-otc
users).

By  way of an introduction, bitcoin-otc is a web of trust specifically
meant to help bitcoin users make trades with each other, trading
bitcoins for goods or other currencies, etc. The typical workflow is
this:
1. one user posts an order, say "buy 10 btc for $30 paypal", and
another user shows interest in the offer.
2. Both users query each other using the bitcoin-wot. This involves
first authenticating them (make sure the right user is logged in)
which might  further involve a query to the keyservers (to associate a
bitcoin-otc IRC handle with an email address). Second, they look at
the global  ratings and transitive trust ratings. One user-friendly
way to interpret  the trust metric is with a graph. Here is an
example: 
http://serajewelks.bitcoin-otc.com/trustgraph.php?source=nanotube&dest=brocktice
3.  After agreeing on a trade, both parties rate each other, -10 to
10,  according to guidelines we provide. For example 1 for one good
trade, 2  for several good trades... 7 and above are reserved for
trusting  personal connections. Using the per-capita-GDP is a possible
variation, which may be easier to interpret than 1-10. Without a
doubt, making these semantics understandable and consistent is an
ongoing challenge. But this is the specific meaning of 'trust' that we
are targeting with this implementation, specifically within the
context of making peer-to-peer trades.

>  1) reuse existing components and standards properly
>
> There are a few minor technical corrections at the end.
>
> Clarity and precision of terminology
> ------------------------------------
>
> The document seems to presume that there is a single thing called
> "trust" that defines a relationship between two people, and that it is a
> linear scale.  This simply isn't the case in the real world, and
> attempts to codify it as such will run into severe problems.

this goes back to the context bit above. sorry if this wasn't quite
clear in the document (though there was the paragraph that mentioned
using different ids for different trust kinds), the particular trust
in question is that of trade trust. i.e., if i send this guy 100 bucks
for this netbook he claims he's selling, how likely am i to get the
goods as described? this is the primary trust issue in the context of
bitcoin, so this is what we're looking at. as you say, there are many
kinds of trust, and they shouldn't be mixed - i am in complete
agreement with that (and which is the reason why i wanted to avoid
using signatures, to avoid mixing trade-trust with identity-trust).

> [snip]
> Additionally, the proposal also seems to sometimes use the term "key"
> when it means "keyholder".  This kind of metonymy is common in everyday
> use, but a technical proposal is no place for sloppiness.

indeed, thanks for pointing that out. this goes back to the informal
roots of this proposal, and i certainly will take your feedback to
heart as i continue working on this.

>
> Reuse existing standards properly
> ---------------------------------
>
> Your proposal suggests using the OpenPGP User ID as a free-form field to
> encode arbitrary data.  Please don't do this.  There currently exists a
> reasonable expectation that a User ID does in fact Identify the User of
> the key (whether it's a human, an organizational role, or a service).
> If a search of keyservers by User ID field returns a bunch of garbage
> about some trust metric, that will be quite annoying.
>
> So what should you use?  OpenPGP already actually has a reasonably
> well-defined "trust signature" subpacket:
>
>  https://tools.ietf.org/html/rfc4880#section-5.2.3.13
>
> But the use of trust here is in the sense of "trusted introducer"
> meaning.  That is, the only type of "trust" they care about is "am i
> willing to rely on the identity certifications made by this person?"
> Even with this reasonable and scoped definition of "trust", this form is
> not in wide use today.  This should give you some pause as you think
> about the likelihood of adoption of the proposed scheme.
>
> Since you probably don't want to use the existing trust packet you
> probably want to make use of OpenPGP's standardized notation format:
>
>  https://tools.ietf.org/html/rfc4880#section-5.2.3.16
>
> Declare a notation, and define its meaning as parsimoniously as
> possible.  The rater could make signatures including this notation over
> the rated person's primary key directly since the proposal doesn't seem
> to care about "real-world" identities.

Well, the use of UIDs rather than signatures with notation data was
actually aimed at /reducing/ the confusion between the identity-trust
commonly used with pgp, and the alter-trust that i'm looking to
implement. a UID with structured data in it is easily visually
identifiable as "something unusual" and wouldn't be confused. notation
data, on the other hand, is not saliently presented on either the sks
keyserver UI, or in the gpg UI, so unless someone digs into it by
looking at packets, they could easily confuse the trade-trust
signature for identity-trust signature. Ultimately, of course there's
really no difference for /my/ purposes whether the signed rating
packet is stored with the rater's key as a UID, or with the ratee's
key as a signature.

> In your FAQ, I note that you prefer a "forward walk" over a "reverse
> walk" through the graph (though i see no justification for this
> preference).  If you think it's really important to place these objects
> on the rater's key instead of the ratee's key, you would be better off
> defining a novel User Attribute (there is a range dedicated to private
> and experimental use so you don't need to petition the registry before
> you have something working) and self-signing it with the appropriate
> information.

yes, well, forward- or backward-walk are really equivalent work-wise,
so i guess that was more of a personal aesthetics issue than a
technical issue, i will admit. :)

> As for your concerns about the GnuPG UI: Yes, you'll need to work on
> changes to the UI.  If you're looking for something that normal humans
> will even begin to consider adopting, you probably don't want the GPG UI
> anyway.  The concept you seem to be proposing (credit-rating in
> particular) is significantly different from the concept GPG's key
> management handles best (identity), so you'll be better off crafting a
> UI that relays these concepts to the user directly.

Indeed, better overlay UIs are certainly planned, but I thought it
would be an important benefit that someone who /wants/ to use stock
gpg /can/ use it (these people would mostly be the geeky types who
know how to use gpg to start with).

>
> To be clear: I don't think it's a good idea to clutter the existing User
> ID space with this proposal as it stands.

Yes, that is the feeling that I'm getting from the replies on this
list so far. I certainly don't want to step on any toes, or intrude on
anyone else's metaphorical lawn, so if there's the concensus that the
SKS people would rather not see this junk on the existing SKS
infrastructure, I won't go that way. A large part of the reason I
posted to sks-devel rather than somewhere else, was precisely in order
to get a feeling for what the SKS people think about our piggybacking
on their infrastructure.

> some specific technical notes
> -----------------------------
>
> 0) "the stock gpg client requires an email address for a UID" -- this is
> not true.

When I tried to create a UID with gpg 1.4.10, it forced me to enter a
non-empty email address, and not only that, but one of the form of
address@hidden If this has been changed in later
versions of GPG (maybe in 2.x?), then that's cool, but I haven't
tested it.

> 1) "To this end, it is also proposed to have a minimum key length and
> type requirement for this first version (4096 bit RSA suggested), to
> make it computationally costly to create bogus identities in the
> system." -- this does not follow.  Creating new 4096-bit RSA keys is not
> a high computational burden.

well, most of the time is used up collecting randomness, rather than
using CPU, but the point stands that it takes longer to create a
larger key, at least in my experience. I certainly haven't collected a
proper data sample to state that with any kind of certainty.

> 2) "...Since the service by design holds private keys of a great number
> of users..."  Please do not encourage or condone the creation of secret
> key material silos in a system that is claimed to be in control of its
> users.  If this is going to be implemented properly, the secret key
> material should remain with the users, not in a service hub.

That's a good point, and I have thought quite a bit about it. My
conclusion is that your average joe is going to be more secure with
the system where the key is escrowed with a third party, and which
uses some kind of two-factor authentication method (yubikey, sms to
cell phone, etc), than he would if he just stores the key on his
computer. If there's anything I learned in the rather short lifespan
of bitcoin (and prior, but particularly so in bitcoin-world), is that
users really really suck at running a secure environment - even when
they stand to lose real money, as in the case of bitcoin wallet theft
due to trojans. And that's not even to mention the numerious cases of
lost data due to lack of backups. So, if it ever comes to pass that
the key on the wot will have any sort of value, the average joes are
going to be losing keys left and right, both due to compromise and
data loss, if they store them on their own machine. It is, in my
experience, and imnsho, much better for the joes to have the option to
escrow the key.

Certainly, those who wish to retain the key locally will have the
option to do so, the whole point of using the public key
infrastructure is to allow people to do what they want, depending on
what fits their level of expertise and use case.

> I hope this critique is useful,
>
>        --dkg

It most certainly is, and I thank you very much for your detailed feedback!

On Fri, Dec 9, 2011 at 9:36 AM, Robert J. Hansen <address@hidden> wrote:
> Trust is a human concept, not a mathematical one.  We all know someone
> who trusts someone they shouldn't, even though they know better.  Odds
> are good that we're examples of this ourselves (I know I am).
>
> OpenPGP gets around this by using the word "trust" in an extremely
> narrow sense, one that makes it useful for a particular task and not
> much more.  This proposal never defines trust with sufficient precision
> for me to feel comfortable with the document: it attempts to create an
> infrastructure to support ... what, exactly?
>
> Until the problem can be precisely and accurately described, no solution
> is possible.
>

Please see my response above. I am sorry if the proposal as is didn't
make it patently clear, but it was originally written for people with
the right context, and I failed to realize that there is that
significant omission from the POV of a third-party reader. As per
above, this is about trade trust, and nothing else.

Thank you all,
Daniel