tor-dev

tor-dev@lists.torproject.org

September 2025

2 participants
2 discussions

Proposal 365, review notes
by Ian Jackson 14 Oct '25

14 Oct '25

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

2 2

Proposal 357, review notes
by Ian Jackson 24 Sep '25

24 Sep '25

Hi. I read the proposal here https://spec.torproject.org/proposals/357-circ-key-exporters.html I had these notes: * AFAICT "KH" is not defined anywhere. At least, there is no cross-reference for it. Perhaps that aspect of the spec should be tidied up first? Or is KH being introduced here? The proposal is unclear. If it is being introduced, it should be defined. * There should be a registry of customisation strings. (Probably one for the whole of torspec) Thanks, Ian.

2 1