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