Subject: Re: [domainrep] Drafting a new use-case: information dissemination ?

From: "J.D. Falk" <[email-masked]>
Date: Mon, 1 Aug 2011 19:32:56 -0700

On Jul 29, 2011, at 3:24 PM, Johan Pouwelse wrote:

> At the 81th IETF BoF I've volunteered to contribute to the hopefully
> soon-to-be WG REPUTE.

Thank you!

> This use case is focussed on collaborative and self-organising systems
> where the users share resources freely.
> We target the following four use case instances:
> 1) open wifi base station - exchanging information between the
> wireless and wired domain.
> 2) Packet forwarding - Relaying packets in an Mobile Ad-hoc Network (MANET)
> 3) Caching proxy - Relaxing information for others in order to
> enhance performance and privacy on the wired Internet
> 4) file sharing - pooling storage capacity together in order to build
> a vast archive of content
> 
> Commonality between the four instances is that without REPUTE there is no mechanism to make an assessment of the trustworthiness of others. Every participant in the above use case instances MUST use REPUTE to determine if it should honour the request for resource usage.

This looks like a perfect fit for REPUTE.  I'd be curious to hear what kind of vocabulary (or similar) you've developed thus far....

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 21:05:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Johan Pouwelse
> Sent: Friday, July 29, 2011 3:24 PM
> To: [email-masked]
> Subject: [domainrep] Drafting a new use-case: information dissemination?
> 
> Dear All,

Hi Johan, glad you were there!

> Proposed use case: information dissemination
> [...]

This seems to me to be a reasonable use case.  What you'd need to do, assuming the proposed framework, is to create a way to identify each of the four use cases you listed so that they can be the subjects of a query.  The trick there is reliable identifiers; if you can't identify uniquely one of the objects you've listed, the reputation can't be trusted because spoofing is possible.

For example, you listed an open WiFi base station.  It's possible to bring up a base station with any SSID you want, so that by itself isn't a reliable identifier; you'd need something more.  Maybe an SSID plus a MAC address or something would work.  People more expert at networking than me would have to weigh in here.

So as long as you can come up with a secure way to identify any of the participants you listed, this framework could be applied by creating one or more vocabularies to describe them and express a reputation about them, like "TRUSTED-BASE-STATION" or "TRUSTED-FORWARDER".  Then it's just a matter of collecting history of co-operation reports about each of them and condensing those reports down into a score that can be reported using our framework.

Thanks for the links to the two papers; I'll check them out soon.

Glad to have you aboard!

-MSK

---

From: Johan Pouwelse <[email-masked]>
Date: Mon, 8 Aug 2011 16:57:49 +0200

> For example, you listed an open WiFi base station.  It's possible to bring up a base station with any SSID you want, so that by itself isn't a reliable identifier; you'd need something more.  Maybe…

Yes, indeed reliable non-spoofable IDs are essential.

For the REPUTE vision I would recommend the usage of "ECDSA and ECDH
Public Keys". The length of the public key is short compared to
RSA-like solutions. Usage with standard X.509 certificates is
described here: http://www.ietf.org/rfc/rfc3279.txt Linking a public
key to a base stations SSID is not obvious. SSIDs have a maximum
length of 32 bytes. So that would be a partial hash of some sort.

Is it deemed useful to subscribe a uniform non-spoofable ID for REPUTE ?

 -johan.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 9 Aug 2011 15:57:50 -0400

> Yes, indeed reliable non-spoofable IDs are essential.

Leaving aside the fact that nothing is completely non-spoofable, I don't think SSID+MAC gets you very far.  Some kind of vendor signature is likely to be essential for any high level of reliability here. 

But I like the basic idea/use-case! -- Nathaniel