Re: [freehaven-dev] Tarzan meeting, Sunday 2:00pm: Agenda attached

[Michael J Freedman <mfreed@MIT.EDU>]

Cool.  And hey, this will probably go past 5, so if you are interested in
dropping by, we are *happy* to have you.

(check one or two threads after my post to find Roger's comments.)

Thanks!
--mike

Fun Sat night too, eh?

At 12:45 AM 3/11/2001 -0500, you wrote:
>Mike,
>
>Just read your agenda.  I'll have a look and send comments tonight if I
>have time...otherwise I'll look it over on Monday.
>
>Nick
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>Nick Feamster                                   feamster@mit.edu
>Massachusetts Institute of Technology           http://www.mit.edu/~feamster/
>440 Massachusetts Ave., Cambridge, MA 02139     (617) 491-3949 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>On Sun, 11 Mar 2001 00:41:19 EST, Michael J Freedman wrote:
>
>> Hey all,
>> 
>> Reminder, we have a meeting tomorrow to discuss the proposed Tarzan design.
>>  Look back over the freehaven-dev archives to find a short description
of it.
>> 
>> 	Sunday, 2:00pm
>> 	MIT Room 2-255
>> 
>> See you tomorrow!
>> --mike
>> 
>> 
>> Agenda Items
>> --------
>> 
>> There are primarily three stages to the Tarzan communications protocol.  
>> 1. Alice and Bob connect to a meeting place.
>> 2. Alice and Bob establish end-to-end communication path.
>> 3. Alice and Bob communication over that path.
>> 
>> We're going to discuss these in depth tomorrow.
>> 
>> 
>> 1. Review proposed session "setup" procedure
>> 	- Alice and Bob connect to Meeting Place
>> 
>> 2. Discuss virtual circuit establishment after "setup" procedure.
>>     	Problem:   Meeting place can read data flowing over it
>>     	Solution?   Setup new keys?  How?  
>> 
>> 		Problem:
>>  		Meeting place can read all non end-to-end 
>> 		PK-encrypted msgs between Alice and Bob.
>> 
>> 		Alice does not necessary know PKs for hops
>> 		used by Bob to connect to Meeting Place.
>> 
>> 		We need entity/key authentication -- something
>> 		like DH key agreement or Shamir's no-key protocol
>> 		not viable.
>> 
>> 		Possibility?  Require extra step for Alice to send Bob
>> 		symmetric keys to use for Bob's hops, which Bob 
>> 		back-propogrates.  This is, um, ugly.
>> 
>> 	Problem:  Meeting place gets loaded to heavily.
>> 		DoS attack - meeting place can only handle one
>> 		incoming connection to Bob at once? 
>> 		TCP multiplexing would be complex!
>> 	
>> 	Alternative?  Alice and Bob connect through a new proxy
>> 		How do they choose, is this protocol getting too
>> 		complicated, etc.  
>> 
>> 
>> 3. Data transmission over circuit
>> 	-- message authentication desirable
>> 	   (MACs on a data stream?)
>>   	-- efficiency:  this is where we want to "win"
>> 
>> If extra time (ha!):
>> 
>> 4. Language war (what do we *really* want)
>> 5. Discussion of key revocation/rotation?
>> 6. Distributed key-value lookup service
>> 
>> 
>> 
>> -----
>> "Not all those who wander are lost."                  mfreed@mit.edu
>> 
>> 
>> 
>> 
>> 
> 

-----
"Not all those who wander are lost."                  mfreed@mit.edu