[tor-dev] Revisiting prop224 cells

[George Kadianakis <desnacked@xxxxxxxxxx>]

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!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev