Re: Some draft notes on migrating Tor's ciphersuites

[Watson Ladd <watsonbladd@xxxxxxxxx>]

One thing that I would like to point out is that .onion addresses will
always contain a public key, and we want to keep them short. This
means ECC (un)fortunately, but apparently DJB has an unencumbered
implementation.
The other thing I would like to note is that when we extend a relay,
we are going to reveal something about the client if we use a protocol
version number that is externally visible to the passing relay. I
don't really see a way around this given that the next relay needs to
know in what format the remainder of the data is in the packet

So I think we also have 2 separate problems here. Problem 1 is this
upgrade, and Problem 2 is future-proofing. Unfortunately they feed
into each other.

What we could do is (depending on how tor responds to unused commands)
is defined EXT_CREAT as packet number 10 which has the format
CircID 2 bytes
10       1 byte
SUITE  1 byte, 0 for this revision.
PAYLOAD  fills remainder of packet.

When a client receives indication that its EXT_CREAT was not
recognized it falls back on CREATE. ORs send back a packet that
indicates if they do not recognize the SUITE and the client falls back
to an earlier revision.
It is important that all clients support only 2 methods to avoid
massive fracturing of the anonymous set. ORs probably also should also
do this.
Anyway, that is my 2 cents.
Sincerely,
Watson Ladd