[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] Tarzan meeting, Sunday 2:00pm: Agenda attached
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.
MIT Room 2-255
See you tomorrow!
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
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
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." email@example.com