[tor-dev] Revisiting prop224 cells
desnacked at riseup.net
Tue Mar 15 16:13:02 UTC 2016
I took a look at proposal 224 again, with the aim of revisiting the cell logic and format.
Here are some matters that require discussion:
1) Should we keep backwards compability with old introduction and rendezvous points?
Currently, proposal 224 actually tries to maintain backwards compatbility but
at the cost of complicating the design. Specifically, to achieve backwards
compatibility we need at least the following functionality:
- Hidden services need to generate and publish an extra encryption key for
each legacy introduction point (legacy enc-key).
- Hidden services need a new cell subtype to register themselves to legacy
introduction points (LEGACY_EST_INTRO).
- Clients need a new cell to introduce themselves through legacy
introduction points (LEGACY-INTRODUCE1)
The above features are not extremely hard to implement, but because of their
hacky backwards-compatible nature they do complicate the protocol and the
code. Also, at some point when the network has upgraded we will have to rip
this code off our codebase, otherwise it will just rot there. Also also, we
will have to write non-trivial chutney tests to ensure the correctness of the
backwards compatibility logic.
Alternatively, we could choose to completely drop backwards compatibility
with old introduction and rendezvous points. This means, that we will have to
wait till a good part of the network has upgraded before we enable prop224
support for clients and services. This means that we will probably have to
wait a whole release cycle (till the relay-side prop224 code becomes stable;
is that 6 months?) before we can globally enable the client/HS prop224
functionality (although we can use the network ourselves for testing prop224
What do you people think we should do here?
Paradoxically, I'm currently thinking of _keeping_ the backwards
compatibility design. Looking at the spec it seems like a medium difficulty
engineering issue for us (maybe an 8% of the total prop224 task size), which
sucks, but at least we don't have to worry about doing proper incremental
deployment of prop224 on the network and worrying about release cycles. Also,
as we move towards implementing prop224 cells, we can reevaluate our position
here. I'm not confident about my position here, so feedback would be helpful.
2) I'd like to simplify the ESTABLISH_INTRO logic.
Currently, ESTABLISH_INTRO seems like a needlessly _complex_ cell that is
It's _complex_ because it takes 3 different forms depending on the value of its
first byte. This complexity is caused partially by our backwards compability
needs (see above), but also because we tried to cram the MAINT_INTRO message
into this cell.
It's _incomplete_ because it does not actually contain the "introduction
point encryption key", so hidden services are forced to send the encryption
key right after the initial ESTABLISH_INTRO cell using a second
ESTABLISH_INTRO cell that is actually a MAINT_INTRO/UPDATE-KEYS-SUBCMD
I have two suggestions here:
* Let's include the intro point encryption key in the ESTABLISH_INTRO cell,
so that hidden services can establish intro with a single cell (not for
performance, but for simplicity).
* Let's introduce a new cell type for MAINT_INTRO instead of cramming it
into ESTABLISH_INTRO. Or at least, let's make it an extension of
ESTABLISH_INTRO instead of using the first byte of the cell to get the
What do you think?
Also, this brings me to the next topic which is:
3) What is UPDATE-KEYS-SUBCMD good for? And why do intro points need to know the
intro point encryption key?
UPDATE-KEYS-SUBCMD seems to be the only use of MAINT_INTRO currently. It
seems to be able to update the encryption keys of an introduction point
circuit on the fly.
But why does the introduction point need to know the encryption key in the
first place? That key is only used by clients and hidden services to encrypt
stuff end-to-end to each other.
After discussing with dgoulet, the only reason I can think of is that so that
the IP is aware of the encryption key, and if an incoming client Alice does
not know the correct encryption key, then the IP can send it to her using an
INTRODUCE_ACK message with [00 02] (and then Alice does not need to refetch
But why would a client know the authentication key but not the encryption
key? Do they have different rotation times? Why would the encryption key
rotate before the authentication key?
Maybe all these things are not necessary for now and we can just ditch
UPDATE-KEYS-SUBCMD completely, assuming that both of those keys have the same
rotation lifetime? And maybe even the IP does not need to know the encryption
key at all?
Am I missing something?
More information about the tor-dev