[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Traffic Analysis (fwd)
Forwarded message:
> Date: Fri, 03 Oct 1997 05:41:58 -0400
> From: "Robert A. Costner" <[email protected]>
> Subject: Re: Traffic Analysis
> At 02:07 AM 10/3/97 -0500, Jim Choate wrote:
> >> For purposes of argument, we could say that a remailer throws away
> >> messages that violate usage policies.
> >
> >Way too high for commercial use. Get it down to something like .01 and that
> >would be workable I suspect (haven't done the math).
>
> You may be confusing actual traffic, with valid customer traffic. (BTW -
> the 10% reject figure was totally pulled out of the air. Since there is no
> logging on a remailer, I'm just making an educated guess.) Almost all
> commercial sendmail implementations reject a large amount of traffic and
> call it "spam filtering". It's very effective, but the fact is that
> incoming mail traffic is blocked before any program such as a remailer can
> see the messages. Some of this is done by IP address, some is done through
> other methods. I'm merely suggesting that a commercial remailer will have
> similar policies.
Duh. Look you picked the numbers and the scenarios, if you got a bitch about
'em talk to yourself...their your ugly baby.
> >Course this raises the
> >issue of who pays for dumped mail on a commercial box. Should the customer
> >pay since it was their action that instigated the drop? Or perhaps the
> >remailer since they were selling a service which they didn't provide at
> >their discretion?
>
> For usage policies, I would think it is the originating user's fault.
Acceptable.
> For
> middleman mail rejects, it is the middleman remailer's fault.
So how do we rollback the payments if say the nth hop breaks the delivery?
If I were a user and one of the remailers dropped the traffic I would want
all my money back, I'm paying for delivery to a specific party.
It is clear that the n-1 remailers has no claim to the charges since the
email was not delivered to the recipient. Yet, it is not fair to take their
income simply because some other remailer dropped mail due to a policy
problem, which they clearly didn't have since they delivered the traffic to the
next hop successfuly. Perhaps the remailer with the restrictive hop should
pay the n-1 remailers. This would certainly provide clear financial
incentive for remailers to have liberal fair use policies (which I support
fully) and act as true commen-carries simply doing a job mechanicaly like
the phone system or the network infrastructure itself. The bottem line is
that if commercial anonymous remailers will survive they have to be as
liberal with handling traffic as my routed is.
> For public
> key errors, it is the originating user's fault.
Is it? If this were commercial systems the key server would NOT be on any
remailers involved otherwise we have a prime target for man-in-the-middle
attacks. So, assuming the user gets the key and the remailers get the keys
from a 3rd party server which delivers the incorrect keys for whatever
reason. Who pays for the failure then? To me it looks like the key server,
but they aren't involved in traffic control but key control. While it is
clearly fair to charge them for costs (say 1 remailer hop) incurred due to
bad keys (which could be the original submitters fault), who pays the other
remailers who handle the traffic and loose the income through no fault of
their own?
Also, what happens if the key is good but the software glitches (which is
indistinguishable from a bad key at the source level)? Are you proposing
we re-send for free all along the chain? I don't think the remailers which
succeded will take kindly to that.
If the MTBF for a remailer is n then the MTBF for m remailers is n*m. In
other words the remailer chain gets less reliable as it gets longer.
> >If I understand you the remailer would send outbound traffic to its input
> >for distribution to your subscribers? I don't believe it would factor into
> >the analysis at all if all the source destinations are the same. Outbound
> >traffic from party A that went to party B would be important to track.
>
> Giving an example that overly simplifies things... I think my idea here was
> that for some number of nyms, they would each receive an average of, say,
> five messages each day. All five messages would be addressed from the
> remailer and PGP encrypted.
Let me say it again, traffic analysis doesn't look at the contents,
cryptanalysis does. Whether the contents are encrypted or not is irrelevant.
The word 'encrypted' NEVER occurs in traffic analysis. You encrypt the
contents because it is assumed that the network analysis has already
succeeded.
Ok, so the recipient has no way to reply to specific parties unless the
contents contain the source address in a source encrypted block. In such a
case Mallet is going to look at the recipient and begin traffic analysis on
them. Which Mallet is going to do as soon as they either submit or recieve
traffic from that node anyway. Seems moot. An effective Mallet collects
statistics on all participants indiscrimenantly.
This is another example of the apparently unrecognized and implicit
assumption that Mallet is only going to look at one party in the chain.
Bad assumption. Traffic analysis will succeed ONLY if the *network* is
analyzed, not some specific node in that network.
This sounds like a message pool where a recipient must attempt decode on
every packet they recieve. The ones not meant for them fail. I don't believe
this is a commercialy viable process because of the amount of work on the
recipients machine.
I have a further question. The cover traffic that shows up in the recipients
mailbox unrequested is spam isn't it? Also, when the recipient uncovers the
last block is it going to say "This space intentionaly left blank"? Or can
users of your remailer expect to recieve email full of hex gibberish they
can't decode since they don't have a key? My suspicion is that if you are
sending cover traffic to anything other than a /dev/null recipient
with an a priori agreement you are not going to keep your users long.
> Four of the messages would be from real people
> trying to communicate with the owner of the nym. One would be a bogus
> message sent to confuse traffic analysis.
Turn those numbers around and you might manage to cover the traffic.
The cover traffic MUST be greater than the 'real' traffic to be effective.
My suspicion based on about 4 months of playing with MixMaster 1.5 years ago
is that this ratio must be several orders of magnitude unless your traffic
is measured in the millions+ of transactions per day.
> All four real messages would
> come into the remailer encrypted to the remailer and addressed to the
> remailer. My thought was that fake outgoing messages to the nym would look
> identical to real messages, thereby helping obscure the "mix" just a little
> better. This helps hide the identity of the sender of the email that is
> headed to a nym.
All the outgoing traffic better look the 'same' it's nothing but a standard
TCP/IP routing header and the contents (which we never look at). The
remailer software is irrelevant on this issue. Traffic analysis relies on
the stability of the protocols and their source & destination info not what
they are used for.
As for the rest of it, take the equation I gave in a previous email and feed
it into a spreadsheet. Develop the equations that define the network using
the same sort of structures and proceedures you use for a travelling
salesman problem (check a local library). If you're asking me to do that
work then I need money, I'll talk about work for free - I don't do work
for free.
> email. The remailer keeps this info in an internal database (as it must)
> and is not available to anyone other than the remailer software.
The remailer only needs records of transactions while a transaction remains
un-committed. The only long term record it should keep is the number of
transactions processed and how much money is currently on the books.
The records are not available unless somebody cracks the box and begins to
tool around the OS ... Mallet is pretty sneaky he reads CERT and collects
hacker software too. If your remailer is keeping records of transactions
after the transactions close you are not secure. You are actualy providing
further incentive to Mallet.
> Having just spent a year and a half involved in a federal court case over
> the 1st amendment right to anonymity on the net, and winning, I'd have to
> disagree with you here. Our affidavit specifically mentioned remailers,
> among other things.
Just exactly where is anonymity mentioned in the 1st? And since it clearly
is not how do you extend:
ARTICLE I.
Congress shall make no law respecting an establishment of religion,
or prohibiting the free exercise thereof; or abridging the freedom of
speech, or of the press; or the right of the people peaceably to assemble,
and to petition the Government for a redress of grievances.
Is your claim that the remailer is a press? (I rhetoricaly bet not) If so
then every computer irrespective of use is a press and protected. Are you
going to follow this line in future cases?
Or is your argument that the traffic is speech and therefore the carrier of
the traffic is immune to prosecution? If so you may have some problems in
the future when the judges and prosecutors get a better clue. Because the
1st's speech clause protects the source of speech not the carrier - that's why
the founding fathers specificaly mention freedom of the press - to extend
that protection to the carrier. Or did you use the commen-carrier approach?
My money is that you used the second line of reasoning which means you can
expect it to be over-turned in the coming years. Unless somebody manages to
get a court to recognize computers as presses and extend those protections
fully or networked computers (not the applications they are put to) in
general as commen-carrier the battle isn't over.
Now if you throw the 9th and 10th in there (which I further rhetoricaly bet
you didn't) you got a winning combo.
Rhetorical question: do you realize that all networked computers are
remailers at the routed level? Did you extend your
argument thusly?
____________________________________________________________________
| |
| The financial policy of the welfare state requires that there |
| be no way for the owners of wealth to protect themselves. |
| |
| -Alan Greenspan- |
| |
| _____ The Armadillo Group |
| ,::////;::-. Austin, Tx. USA |
| /:'///// ``::>/|/ http:// www.ssz.com/ |
| .', |||| `/( e\ |
| -====~~mm-'`-```-mm --'- Jim Choate |
| [email protected] |
| 512-451-7087 |
|____________________________________________________________________|