On 03/12/2014 02:30 PM, Amir Taaki wrote:
> Well being able to issue keys is an important mechanism to prevent
> starvation attacks. The idea is that you issue keys and provide
> the Obelisk servers as a service. If someone abuses their access,
> you revoke their keys and they can't keep creating more.

Certainly, but the problem, as with all distributed key systems, is
the key distribution. How do "authorized" wallet clients get keys?

Enterprise network hosts get an identity cert as a result of the
"domain join" process. This requires a network admin to visit each
machine and, using network admin creds, cause a server to emit a
certificate to the client, which the client then stores "securely".
This is then used to provide identification and periodic refresh of
Kerberos tickets.

What you are describing would, for all intents and purposes, require
the same flow. Manual cert distribution and security is fine for
physically secured server environments, but there's no practical
equivalent for clients.

> The other case is where you use Obelisk as a backend for your
> website. Maybe it runs on a different box. You whitelist the IP
> address you access it from and setup a keypair between client and
> server which doesn't allow access from other hosts or IP
> addresses.

Absolutely, I wasn't thinking of that context. A sever environment on
a local subnet could probably get by with IP addresses for identity.
But if you have a distributed set of services that are coordinating
and deployed across a public network you would want identity certs.
This would be common in an AWS deployment, for example.

> About discovering server keys and servers in general, we need to
> develop something. I think it's better to wait and think something
> through. My proposal is a special daemon (maybe part of Obelisk)
> which servers can register themselves with, register which methods
> they implement and the documentation for those methods (allowing
> remote introspection by client developers). This would allow
> discovery and all kinds of nice stuff.

As a reference there is a large body of work around web services
discovery in WSDL:

http://en.wikipedia.org/wiki/Web_Services_Description_Language

This is typically integrated into web services frameworks, like Java's
WSIT and .Net's WCF. But as I understand it the specification stands
alone. It is probably too heavy, but may at least provide a fairly
comprehensive reference.

WRT discovery of server public keys, that's another issue altogether.
If the key is meant to verify server identity then it can't be
published by the server. This is the key distribution problem again.
Public keys need a trusted means of distribution.

For this there is PKI and WoT, and I'm assuming PKI is out. This means
distribution of public keys redundantly and widely - since any single
untrusted channel of distribution should be assumed to be compromised
(and establishing trust is the core problem). More here:

http://en.wikipedia.org/wiki/Web_of_trust

My suggestion that keys be published via the Wiki is just a
recognition that in a WoT model they need to be published widely, and
that would be a starting point. I don't think anything can be
integrated into the servers to improve this.

As with any identity cert system key revocation is also an issue. The
revocation needs to be published as broadly as the key was. It would
be very nice if existing key servers could be utilized for this:

http://en.wikipedia.org/wiki/Key_server_(cryptographic)

e

> On 12/03/14 20:13, Eric Voskuil wrote:
>> Thanks for getting this integrated Amir, privacy on the wire is
>> a necessary piece in the anonymity puzzle!
>>
>> There needs to be a mechanism for publication of server public
>> keys. Adding this field to the published list of Obelisk servers
>> <https://wiki.unsystem.net/index.php/Obelisk/Servers> would be a
>> good start.
>>
>> When it comes to client implementation I would expect that a
>> client would maintain its whitelist of servers (i.e. those for
>> which it has public keys) and not typically utilize a persistent
>> keypair (i.e. would remain anonymous to the server) - as in
>> scenario 3 from the CurveZMQ docs:
>>
>> "Where the server does not check client keys at all. In this case
>> the clients can be certain they are talking securely to the
>> correct server, but the server will accept connections from any
>> client. This fits the conventional Internet model where a browser
>> talks securely to a website to place and order and send credit
>> card information."
>>
>> This would also mean that the server whitelist of clients would
>> not be typically utilized by a public server.
>>
>> e
>>
>> On 03/12/2014 10:14 AM, Amir Taaki wrote:
>>> Hey, The new Obelisk has support for server-client encryption
>>> and signing using ed25519 crypto. The client can specify a key,
>>> and the server can specify which client pubkeys it will accept
>>> (or all) and a whitelist of IP addresses.
>>
>>> See this config file for reference:
>>
>>> https://github.com/spesmilo/obelisk/blob/master/src/worker/worker.cfg#L24