mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
f0b131f1c0
to proposal 110. the proposals that were around before the proposals scheme got started still don't have dates. svn:r9815
100 lines
3.5 KiB
Plaintext
100 lines
3.5 KiB
Plaintext
Filename: 098-todo.txt
|
|
Title: Proposals that should be written
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Nick Mathewson, Roger Dingledine
|
|
Created: 26-Jan-2007
|
|
Status: Meta
|
|
|
|
Overview:
|
|
|
|
This document lists ideas that various people have had for improving the
|
|
Tor protocol. These should be implemented and specified if they're
|
|
trivial, or written up as proposals if they're not.
|
|
|
|
This is an active document, to be edited as proposals are written and as
|
|
we come up with new ideas for proposals. We should take stuff out as it
|
|
seems irrelevant.
|
|
|
|
|
|
For protocol version 2:
|
|
|
|
- Fix onionskin handshake scheme to be more mainstream, less nutty.
|
|
Can we just do
|
|
E(HMAC(g^x), g^x) rather than just E(g^x) ?
|
|
No, that has the same flaws as before. We should send
|
|
E(g^x, C) with random C and expect g^y, HMAC_C(K=g^xy).
|
|
Better ask Ian; probably Stephen too.
|
|
- Versioned CREATE and friends
|
|
- Length on CREATE and friends
|
|
- Versioning on circuits
|
|
- Versioning on create cells
|
|
- SHA1 is showing its age
|
|
- Not being able to upgrade ciphersuites or increase key lengths is
|
|
lame.
|
|
- Paul has some ideas about circuit creation; read his PET paper once it's
|
|
out.
|
|
- Allow more TLS ciphersuites.
|
|
|
|
Any time:
|
|
|
|
- Some ideas for revising the directory protocol:
|
|
- Should we also look into a "delta since last network-status
|
|
checkpoint" scheme, to reduce overhead further?
|
|
- Extend the "r" line in network-status to give a set of buckets (say,
|
|
comma-separated) for that router.
|
|
- Buckets are deterministic based on IP address.
|
|
- Then clients can choose a bucket (or set of buckets) to
|
|
download and use.
|
|
- We need a way for the authorities to declare that nodes are in a
|
|
family. Also, it kinda sucks that family declarations use O(N^2) space
|
|
in the descriptors.
|
|
- REASON_CONNECTFAILED should include an IP.
|
|
- Spec should incorporate some prose from tor-design to be more readable.
|
|
- Spec when we should rotate which keys
|
|
- Spec how to publish descriptors less often
|
|
- Describe pros and cons of non-deterministic path lengths
|
|
- get rid of the Named flag, or automate it at the dir auth end,
|
|
or automate it at the client end, or something.
|
|
|
|
- We should use a variable-length path length by default -- 3 +/- some
|
|
distribution. Need to think harder about allowing values less than 3,
|
|
and there's a tradeoff between having a wide variance and performance.
|
|
|
|
Things that should change...
|
|
|
|
B.1. ... but which will require backward-incompatible change
|
|
|
|
- Circuit IDs should be longer.
|
|
- IPv6 everywhere.
|
|
- Maybe, keys should be longer.
|
|
- Maybe, key-length should be adjustable. How to do this without
|
|
making anonymity suck?
|
|
- Drop backward compatibility.
|
|
- We should use a 128-bit subgroup of our DH prime.
|
|
- Handshake should use HMAC.
|
|
- Multiple cell lengths.
|
|
- Ability to split circuits across paths (If this is useful.)
|
|
- SENDME windows should be dynamic.
|
|
|
|
- Directory
|
|
- Stop ever mentioning socks ports
|
|
|
|
B.1. ... and that will require no changes
|
|
|
|
- Mention multiple addr/port combos
|
|
- Advertised outbound IP?
|
|
- Migrate streams across circuits.
|
|
|
|
B.2. ... and that we have no idea how to do.
|
|
|
|
- UDP (as transport)
|
|
- UDP (as content)
|
|
- Use a better AES mode that has built-in integrity checking,
|
|
doesn't grow with the number of hops, is not patented, and
|
|
is implemented and maintained by smart people.
|
|
|
|
Let onion keys be not just RSA but maybe DH too, for Paul's reply onion
|
|
design.
|
|
|