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

Re: Netescrow & Remailers?



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.

| 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.

	That requires prior arrangement.  The nice thing about
Netescrow is if the remailer goes down in flames, and Raph and Lance
and Matt call for its key to be recovered, everything sent before the
remailer went down, intended to chain through it, can still go
through, albeit with a delay.

| 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.
| 
| However, some questions for this scenario:
| 
| -- users will have "[email protected]" in their scripts, or chains, or
| whatever. So, having Bob have AliceKey is not ipso facto very useful. If
| users have to respecify a site name, they might as well just switch to the
| BobPublicKey, for example.

	If thats [email protected], then alias.net can use MX
records to redirect the mail.

| -- on the other hand, if a "logical name" could be used, where users see a
| name like "AliceRemailer" instead of "[email protected]," then a remapping of
| AliceRemailer to whatever site is still up and handling her private key
| could provide a seamless transtion.

	Logical mappings are already provided by MX records.

| 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.)

	Or if the remailer operator is disappeared; this is the win to
Netescrow for remailers.  The key can be recovered, but this needs to
happen in a public way.  If the operator is still around, they can
broadcast a "Hey! Don't do that" message.

Adam

-- 
"Every year the Republicans campaign like Libertarians, and then go to
Wasthington and spend like Democrats."

Vote Harry Browne for President.  http://www.harrybrowne96.org