Opened 4 weeks ago

Last modified 3 weeks ago

#26431 new task

Document a threat model for stem.client

Reported by: dmr Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Stem Version:
Severity: Normal Keywords: client website
Cc: atagar, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It would be beneficial to document the threat model that stem.client is trying to meet (and thereby, probably some of the use cases envisioned for stem.client).

From a network-fingerprint sense, it is unlikely that stem.client could ever match the fingerprint that little-t tor does, since stem.client is a pure-Python implementation. Some side-channel behavior in particular is likely to be extremely difficult to align, and different Python implementations would make this even harder.

But how close should stem.client come, how closely should it track to tor development, and what should it take into account?

Some of this discussion may ripple into updating the tor-spec with some SHOULD statements.

In general, it's important to document the threat model so that consumers of stem.client can know what to expect, and whether they should use tor in a controlled fashion instead.

This threat model should become a living document that is maintained.

Child Tickets

Change History (2)

comment:1 Changed 3 weeks ago by atagar

Thanks dmr. I'm not against a Stem threat model per say, but my main interest in Stem is to be a python implementation of the Tor specification. If we have security expectations for alternate Tor implementations then maybe that should live with the specs?

comment:2 Changed 3 weeks ago by teor

Our security expectations of alternative tor implementations are pretty simple:

  • We do not expect alternative Tor implementations to be able to emulate C Tor's behaviour, so they are their own anonymity sets (there are several research papers on protocol emulation for anonymity: it doesn't work)
  • For this reason, and many others, alternative Tor implementations should not claim to support anonymity or privacy that is as good as Tor's: https://www.torproject.org/docs/trademark-faq.html.en

So I'm not sure that writing a spec like this would be useful. A few sentences of threat model should be sufficient:

stem.client does not make you anonymous. Use Tor Browser if you want to be anonymous. (Link to Tor Browser download page.)

When we have a draft guide for embedding Tor in other browsers (like Firefox, Brave, or Cliqz), it might contain some useful information about threat models for alternative implementations.

Note: See TracTickets for help on using tickets.