Opened 3 months ago

Last modified 7 weeks ago

#26431 assigned task

Document a threat model for stem.client

Reported by: dmr Owned by: dmr
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 (5)

comment:1 Changed 3 months 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 months 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.

comment:3 Changed 8 weeks ago by atagar

Status: newneeds_information

Hi Dave, do we still need this ticket?

comment:4 in reply to:  3 ; Changed 8 weeks ago by dmr

Owner: changed from atagar to dmr
Status: needs_informationassigned

Replying to atagar:

Hi Dave, do we still need this ticket?

I think the original questions prompted by the ticket have been answered by teor.
However, I'd like to keep the ticket open - I think it should be documented to make sure this is readily apparent to stem.client consumers.

I view this as something to be done at the time that a user-facing API is described.

Assigning to self - I can take of this.

Replying to teor:

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.

teor, do you know where this info will live? It would be great to link to (at least, eventually).

Last edited 8 weeks ago by dmr (previous) (diff)

comment:5 in reply to:  4 Changed 7 weeks ago by teor

Replying to teor:

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.

teor, do you know where this info will live? It would be great to link to (at least, eventually).

I don't know, because the Tor Browser team hasn't created the document yet.

Note: See TracTickets for help on using tickets.