[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Notes from Codecon Remailer BOF (3 weeks late)



Notes from CodeCon Remailer BOF; February 2003; San Francisco
=============================================================

This is a transcript of my notes from the BOF; if you were there,
your recollections may be different than mine.  The agenda of the BOF
was to discuss issues that seemed both pressing and resolvable -- in
other words, that seemed doable for the next software release.

[A note on the code status: I've been starting a new job this month,
 and haven't made a lot of progress in coding Minion while I ramp up.
 I expect to get back to Minion coding in the next week or so.]

Notes by issue:

1) How should remailer nodes track packet statistics?  (e.g., number
   of packets received, sent, etc.)

   We decided: "daily or hourly".  Len said that he had a list of
   events that we should consider tracking, and that he'd email it.

2) MIME encoding?  If we're going to be compatible and competitive
   with existing email systems, we'll need to deliver messages with
   types, with multipart features, and with multiple alternative
   formats.  This argues for delivery as MIME messages.  But we have
   avoided MIME in the past, because different MIME implementations
   are distinguishable in their output.
 
   We decided to look into the difficulty of specifying a "canonical
   MIME" layer to provide a version of MIME with less
   distinguishability.  This will/may be very hard.  Hopefully
   somebody else can do it.

   It was suggested that we work on an RFC on 'canonical MIME for anonymity
   networks.' 

   A counterargument: Do we anonymize all dataformats?  JPEGs, mp3s,
   and word documents all leak obscene amounts of information about
   their creators. 

   Really, this is a morass, and might need to be a separate project
   all in itself, but if so, it's a separate project that needs to get
   done if we want users.  Joe Average doesn't know from HTML mail vs
   text vs mime-multipart.

   [Note to readers: Don't get to worried about this part; nobody
   will be coding it for a while, methinks]

3) Load testing and integration testing.  We decided it wasn't very
   worthwhile to expect much from integration tests, but that we
   should have some scripted tests at least to check whether all the
   command-line function works.

   For simulation purposes: I'm supposed to email Raph for info on
   power law networks.  These are supposed to be good simulations of
   how network traffic actually behaves.

4) We decided that users should be allowed to set the subject line of
   outgoing email.  

   On setting "From" lines: Noise pointed out that people may want to
   send one-off messages that don't seem to originate from "nobody".
   Many of us thought, however, that settable from lines would create
   a severe abuse opportunity.  It's possible that having nymservers
   send messages with "From" lines may help some users with this
   demand, but not others.

   This choice is one we'll need to make.  Leaving the choice up to
   exit node operators is not a good option: that would make users 
   more partitionable based on their paths.

   [One possible alternative: Allow the user to set only part of the
   "From:" line.  For example, the from line could always appear as:
   'From: "XXXX (Anonymous user)" <nobody@nowhere.net>', but the user
   could set the XXXX part.]

5) We discussed how to handle MMTP key rotation, and discussed
   whether it was easiest to get MMTP authentication at the expense
   of dropping server authentication.  On further examination,
   however, it turns out that the existing code mis-implements the
   spec; I'll fix the next version so that servers are authenticated
   based on their identity keys, not on their temporary MMTP keys.

6) Looking at the state of the art in RSA attacks, and considering
   the public-relations advantage of supporting larger key sizes, we
   decided that the size of packet keys should be increased to 2048
   bits.

   [There's a neat way to do this without bloating the header size or
   limiting the number of hops.  Currently, to add a new layer L to
   an unencrypted header H, we do:
             H' = PK_ENCRYPT(K, L) | ENCRYPT(H)
   Instead, we can do:
             H' = PK_ENCRYPT(K, L | H[0:N]) | ENCRYPT(H[N:len(H)])
   where N is the maximum number of bytes of H that will fit in an
   single encrypted chunk with L.  This way, even though we're using
   larger packet keys, we actually _save_ space in the header.]

   Using longer keys will hit our throughput, but we decided that it
   was worth it: decent hardware can still saturate a decent net
   connection, if our numbers are right.

7) Key rotation is problematic.  There are two parameters we need to
   set: how often keys rotate (lifetime), and how long after its
   rotation a key remains valid (overlap).

   For reliability and convenience, we'd like long lifetimes and high
   overlap.  But high overlap enables delaying attacks, and long
   lifetimes exacerbate the exposure if keys are compromised. 

   We decided that the best answer for now is to admit we don't know
   the best settings here, and that we'll need to experiment a bit to
   find the right answers.

8) Directories: We decided that the hardest part of directories is
   cross-directory agreement, and that we should implement the rest
   (automatic publication, built-in pinging) sooner, and not wait
   till we get coordination figured out.

   Coordination among directories and how to agree on list of good
   directories is open topic.  The issues are numerous, and
   nontrivial.  Lucky favored a closed coordination process, where
   directories don't publish intermediate values but use SMC to arrive
   at a common value.  Nick favored an semi-open process, with
   intermediate votes published.  Each believed that the opposite
   approach could enable dangerous social engineering attacks: if
   intermediate results are fully open (Lucky says) then a social
   engineer can coopt their credibility by publishing an "Even Better
   Directory Based On Results You Trust".  If intermediate results (at
   least votes) are not open (Nick says) then a social engineer can
   undermine the system's credibility by attacking the "Secret Cabal
   Of Directories With A Hidden Agenda And No Accountability".

   Raph had some ideas about how to achieve trust among directory
   servers -- either to determine who the good directory servers are,
   or to establish a consensus list of remailers directly.  This does
   seem to be yet another case of Raph's work on trust computation,
   but (still) nobody but Raph seems to understand the field well
   enough to channel him.

   We'll all need to look at Byzantine Fault Tolerance again; if
   Lucky's right, we'll want to look at Secure Multiparty Computation
   too.

Yrs,
-- 
Nick

Attachment: signature.asc
Description: This is a digitally signed message part