[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Netescrow & Remailers?
Tim May <[email protected]> writes:
> At 10:54 AM -0500 10/23/96, Adam Shostack wrote:
> > Would it make remailers more reliable to use a netescrow
> >system, so that if a remailer goes offline, the others can request its
> >keys, and continue moving its messages?
> >
> > To me, reliability is as large a problem as UI. If the next
> >Mixmaster is going to do direct IP transport, reliability could
> >increase as a problem.
>
> This seems like a very good idea. I have an idea for transitioning from the
> current "physical site name" approach remailers are using, to perhaps a
> "logical site name," where logical names (like "AliceRemailer") would be
> aliased or mapped (through a collectively-maintained, or Raph
> Levien-maintained (:-}) list of logical-to-physical site names. Thus, if
> the physical site or physical account name which maintained the
> "AliceRemailer" remailer and keypair were to vanish or have the account
> yanked, another site/account could "inherit" the keypair (by suitable
> arrangements) and the persistence of the site AliceRemailer would be
> ensured.
As Adam (Shostack) suggested, and also as discussed by John Gilmore in
response (on coderpunks) to my reply to his "anonymous.net" proposal,
MX records provide a way to do this.
John was talking about using "[email protected]" as a single
entry point into the remailers in general, with multiple MX records
meaning that the mail would go to random actual remailers. The
remailer would then forward to the correct remailer.
Also suggested was "[email protected]", which would
again me MXed to a particular remailer. The same technique would
allow MX records to point to remailers by name rather than being
numbered. Your Alice becomes <[email protected]>
using MX forwarding (or [email protected], the other domain
used for remailer MX redirection).
And of course the nice thing about MX records (and A records) is that
they have TTLs (Time To Live) which when set appropriately means that
they can be made to point at different IP addresses at the drop of a
hat. And the old email address works as before (once you've also
reallocated the key).
> But I have some questions about possible implementations. Suppose a
> remailer is named "[email protected]," or "Alice" for short. Alice has a key,
> AliceKey.
>
> Now imagine that the Alice remailer goes down, for whatever reason. Alice
> (the person or owner) can "authorize the release of AliceKey" to another
> remailer of her choosing (or by prior arrangement, as a fallback remailer).
> So, Bob takes over Alice's traffic.
>
> [...]
>
> I don't see that this would create new security problems, as the private
> keys for a logical remailer are only passed on to another site if and when
> the remailer owner _wants_ to. (This is back to the familiar theme that the
> owner of a private key can pretty do what he wants, including passing it on
> to others.)
I was thinking of the same idea, of reallocating keys, and one issue
which did occur to me, is that when remailer Alice goes off-line this
is as like as not to be the result of some law enforecement (LE)
interference. If the LEs also happen to own a few remailers, they may
`encourage' the remailer operator to hand over the key to one of their
own remailers.
It might be nice if the attacked remailer was able to hand the keys to
a random other remailer, in such a way that it was publically
verifiable that the selection was random, and verifiable as to which
remailer got the key. (The remaining remailers engage in a publically
verifiable cryptographic selection of straws, the shortest straw gets
the key).
Naturally there is nothing to stop any given remailer giving the key
away to all and sundry, and nothing to stop the spooks starting lots
of remailers.
Also if the spooks own more than half the remailers the above may be
worse than the remailer owner giving the key to a trusted friend.
Another approach would be for the remailer to release a timestamped
hash of it's key reallocation policy. When the remailer is
decomissioned, this will allow people to see that it is adhering to
it's stated policy. (The policy could specify a verifiable random
selection from a list of remailers selected by the owner).
However I think it is nice to know when there is increased likelihood
of spook interference that the reallocated key gets a fair chance of
being redistributed to a non spook remailer, or according to the
owner's uncoerced wishes.
Also it is nice to know which remailers are run on the same machine,
and/or owned by the same operator, if for no other reason, than to
allow you to take this into account when generating your chains. I
notice Raph's reliable remailer list includes this information where
it is known:
: Groups of remailers sharing a machine or operator:
: (cyber mix)
: (weasel squirrel)
These remailers are of less value when used together in a chain, in
the case of security compromise on the machine, or operator coercion,
than remailers with different operators. This kind of information is
valuable just as the remailers other attributes are: the remailers
jurisdiction, and the owner's usage policy.
Matts Kallioniemi <[email protected]> reminded us, of a point made
in early rehashes, that we really need disposable last hop remailers.
The interesting point he made, which I had not seen made before, is
that exit remailers could refuse to remail to other remailers, to
discourage use in reply blocks, or at least a tag "exit" could be
added to the Raphs remailer capability list, so that people know that
these remailers are likely to take the heat.
The converse, specifically non-exit remailers, there exists only one
example that I have seen advertised, "middleman". Matts' suggestion of
having all remailers either "exitmen" or "middlemen", seems like a
good idea.
However there are other reasons remailers shut down at short notice,
(other than being attacked by LEs, or having legal threats made).
Amongst these we've seen:
- "sorry folks, I'm taking my laptop on holiday"
- "sorry, remailers keys lost in disk crash, heres a new key"
- "my ISP is shutting down"
- "shut down due to abuse"
- "sorry remailer key compromised"
plus no doubt many temporary outages caused by machine reboots,
network outages, software upgrades, rebooting a linux machine to DOS
to for a while, etc.
It would be really nice if remailers could be made completely
disposable.
Tom Cross <[email protected]> described an idea in the
remailer thread on coderpunks. His idea was to have the remailers in
a DC net, and have pseudonym servers as the DC net nodes. He also had
redundant secret sharing for the pseudonym <-> reply block database,
to provide resilence to individual DC net nodes bowing out. This
prevents attacks on the pseudonym server (coercing the pseudonym
server to delete a particular pseudonym and it's reply block), but
doesn't say anything about the resilence of the reply block itself to
remailers in the chain disappearing.
A method relying on DC nets would be for the nym owner to create a
single hop reply block, and secret share this reply block over the DC
net nodes. If a request is sent to any DC net node, provided that the
required k of n share holders remain, the reply address can be
retrieved. You would need to ensure that the reconstruction of
recipients address did not reveal shares.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`