Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #26431

Closed
Open
Created Jun 20, 2018 by dmr@dmr

Document a threat model for stem.client

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 [[https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt|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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking