Hello,
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 till then).
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 also _incomplete_.
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 message.
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 cell subtype.
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 the descriptor).
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?
Cheers!