[tor-dev] Proposal 365, review notes

[Ian Jackson via tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>]

Hi.  I read the proposal here
  https://spec.torproject.org/proposals/365-http-connect-ext.html

I hate these notes:

* Tenses are weird.

  The whole proposal is written in a weird mix of tenses and sometimes
  in a weird mood.  Writing the specifications in the future tense is
  confusing and will make moving the text to the main spec (which we
  should do after approval and as part of implementation) much harder.

  There should not be statements like "we should".  Specifications, even
  proposals, should be definitive and therefore should be definite.

  So everything should be written in the present imperative.

* "X-Tor-RPC-Target: Arti RPC support" is weird.

  Firstly, is this being a protocol registry?

  Secondly, do we not have a notion of critical extensions?
  We should be using that for something like this.

* Proxy-Authorization

  Don't we need to continue to support http clients where we can't
  specify custom headers?

  If so then this spec is a recipe for continuation of the bad protocol
  where we use the whole of the Proxy-Authorization contents as an
  unconditional input to isolation.

* Optimistic data 

  This has a framing hazard, which could be a vulnerability in some
  circumstances.  I wrote about this in this torspec MR
    https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_3236424

  AFAICT that means if that MR merges, this feature will be removed?
  That would resolve the concern.

* "X-Tor-Family-Preference: IP version preferences"

  What is this for?  Is there not an existing way to control this over
  HTTP?

* "X-Tor-Proxy: Indication for Tor proxy protocol support"

  Why does this need to be separate from the X-Tor-Capabilities ?

* Capabilities

  > Clients SHOULD NOT inspect the contents of this header to determine
  > whether a given feature is supported or not.

  Should be MUST NOT.  Capability guessing via version strings is
  completely terrible.

  I suggest:

      Clients MAY use this to determine whether some software has a
      particular bug, but the matching MUST NOT treat any future versions
      as buggy.  So the bug must be fixed before this technique can be
      used.

  (This is the rule adopted by the PuTTY team for compatibility with
  broken ssh servers.)

Thanks for your attention,

Ian.
_______________________________________________
tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx