[tor-dev] Re: Proposal 365, review notes

[Nick Mathewson via tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>]

On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev
<tor-dev@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi.  I read the proposal here
>   https://spec.torproject.org/proposals/365-http-connect-ext.html

Hi, thanks for the tenses!

> 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.

I'll try to do this in a revision.

> * "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.

What is the "this" that you're asking about in the sense of being a
protocol registry, and how would it be a protocol registry? Do you
mean, are we starting a list of special Tor HTTP CONNECT extensions?
If so, we already have such a list in
https://spec.torproject.org/http-connect.html .  But I think you must
mean something else?

As for critical extensions: I don't think HTTP does those?  Even if we
add a specific "critical extension" mechanism to our own headers, we
can't rely on any other implementation rejecting requests that have
them.

We _could_ say that some extensions are "critical" from a Tor POV, in
the sense that they mean "you must either implement this or reject it
if you are a Tor implementation".  Is that what you have in mind?

I don't  think I'm understanding your questions very well here; maybe
we should meet once you're back.

> * Proxy-Authorization
>
>   Don't we need to continue to support http clients where we can't
>   specify custom headers?

I think so, yes.

>   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.

The idea here is that the existing mechanism (using the whole
proxy-authorization content) would work, but it would be deprecated
and cause a warning when used, whereas the new scheme (using Basic
with username x-tor) would be the non-deprecated thing.  I'll add a
note about deprecation.

> * 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.

Yes; I'm just waiting for some of your replies on that ticket.

> * "X-Tor-Family-Preference: IP version preferences"
>
>   What is this for?  Is there not an existing way to control this over
>   HTTP?

I cannot find any such header for regular HTTP.

> * "X-Tor-Proxy: Indication for Tor proxy protocol support"
>
>   Why does this need to be separate from the X-Tor-Capabilities ?

The idea is that this tells you what the proxy implementation is, and
that you'd use it for bug-checking as noted below.

> * 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.)

Agreed.

====

Please let me know what you think about the places above; I'll start
revisions on this once I know what you think.

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