Tim May <tcmay@got.net> 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 "remailer@mail.anonymous.net" 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 "remailer@1234.mail.anonymous.net", 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 <remailer@alice.mail.anonymous.net> using MX forwarding (or remailer@alice.alias.net, 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 "Alice@foo.bar," 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 <matts@cyberpass.net> 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 <Decius@ninja.techwood.org> 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`

Adam Shostack writes:

Timothy C. May wrote:

| I don't think "escrow" is the salient feature of what Adam is hinting at, | or at least it's now what I'm focussing on here. Rather, I think the really | intriguing thing is using _logical_ names for remailers, and not | necessarily tying them to specific accounts, specific account owners, or | specific sites. ("Call by name," if you will.) This could make remailers | more persistent.

Netescrow is a system that Matt Blaze proposed to do key escrow such that the recovery of a key must be public.

Someone wrote me a while back asking about using oblivious key escrow ("netescrow") to build a remailer. I was a bit skeptical of using exactly the mechanism that I outlined in my paper on the subject, but I think the idea raises some intersting avenues to look at. I'll try to dig up the message I sent on the subject. -matt The paper in question, by the way, can be found at: ftp://research.att.com/dist/mab/netescrow.ps