Some draft notes on migrating Tor's ciphersuites

[Robert Ransom]

On Sun, 19 Dec 2010 08:46:13 -0500
Watson Ladd <watsonbladd at gmail.com> wrote:

> On Sat, Dec 18, 2010 at 10:34 PM, Nick Mathewson <nickm at freehaven.net> wrote:

> > You're right that it's important to limit partitioning opportunities
> > in any protocol revision; I tried to go over that in section 2, but we
> > shouldn't assume that I've said the last word on this.  We should
> > continue to look for ways to revise and improve whatever we come up
> > with to get the partitioning and other undesirable things down to a
> > minimum.

My current plan to minimize partitioning of the client anonymity set is:

* The directory authorities should specify lists of cryptographic
  primitives (identity key signature systems, circuit-extension
  handshakes, circuit ciphersuites, etc.) that relays are permitted to
  support in the consensus.

* The directory authorities should specify lists of cryptographic
  primitives that clients should consider using in the consensus.

* Each relay should specify lists of cryptographic primitives that it
  is willing to use in its descriptor, ordered by the relay's
  preference (e.g. the relay puts its favorite primitive in a list
  first).

* A client should select the first cryptographic primitive in a relay's
  list that (a) the consensus recommends that clients use, and (b) the
  client supports.

* The Tor developers should not introduce new cryptographic primitives
  between two stable releases in the same branch.

The Tor client will need to support torrc options that override the
lists of recommended cryptographic primitives in the consensus in order
to allow testing of not-yet-recommended primitives on the public Tor
network, but the manual page will need to warn explicitly that setting
those options will harm a Tor user's anonymity.

This plan relies on the directory authorities not recommending a new
cryptographic primitive until a large fraction of Tor clients support
it.


> One way is to be very conservative in suite choices so we don't have
> to change them that often. I'm going to also go out on a limb and say
> that we also want a crypto API like NaCL that lets us just say
> enciphered=encrypt(key, unenciphered) and doesn't force us to worry
> about padding or modes because this is a much simpler abstraction
> layer and so offers less opportunity for mistakes that could threaten
> security.

I think that if we follow the plan above, we don't need to limit the
number of cryptographic primitives of each type in order to preserve
the client anonymity set.  It's more important to have at least two
cryptographic primitives of each type implemented, even if we expect
that few relays will prefer one of them, in order to ensure that we get
the APIs for each primitive right.


Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20101231/10209555/attachment.pgp>