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

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

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!

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?  

 		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