Hi Yaroslav, thanks for the reply, and no worries - I've been slow to respond on this thread as well, sorry. Responses inline. David
On Fri, Jan 30, 2026 at 11:46 AM Yaroslav Rosomakho <[email protected]> wrote: > Hello David, > > Apologies for the very late response.... Please see comments inline below. > > On Sat, Dec 13, 2025 at 6:05 PM David Schinazi <[email protected]> > wrote: > >> Added text to clarify that ".well-known/pvd" path and port 443 are the >>> defaults that may be overridden by a local policy. >>> https://github.com/tfpauly/privacy-proxy/pull/314 >>> >>> Defaulting to the configured proxy port has a number of potential >>> problems: >>> - a non-authorised user may be running a proxy on a high port and use >>> that to poison config >>> - a proxy running over HTTPS on a non-standard port is not guaranteed >>> might not be able to act as a web server and provide configuration >>> information >>> >>> >> I don't think that local policy is the right framing here. I can imagine >> two uses of this specification: >> (1) the client got figured with a proxy with some other means - let's say >> the system told it to use SOCKSv5 >> (2) the client got configured with a PVD URI >> >> For scenario (1), I agree that you need to force the port and the URL, >> because all you have is a hostname and another port that doesn't speak >> HTTPS. >> But for scenario (2), I'd like to configure the client with " >> https://website.example:8443/proxying/pvd"; and have that contain a >> connect-udp URI template on the same origin. >> >> Making this a matter of local client policy doesn't allow that. Instead, >> I would suggest switching the framing to say that the PVD is represented by >> a URL, and separately have a way to determine the URL if all you have is a >> hostname. >> >> > The authors' position is that automated retrieval of proxy configuration > over HTTPS on non-standard (especially non-privileged) ports introduces > additional security risks. It increases the attack surface for > configuration poisoning and makes it harder to reason about trust > boundaries, origin validation, and expected server behaviour. > While these risks could be mitigated (for example, by constraining > acceptable proxies to the same port as the PvD fetch), doing so introduces > additional complexity and corner cases that are likely to be error-prone in > practice. > HTTPS-based proxies on non-standard ports are most commonly deployed in > lab or test setups, rather than at production scale. Given that, the > authors feel it is reasonable to treat such behaviour as a matter of local > policy rather than a normative default. > This approach keeps the base specification simpler and more conservative > from a security standpoint, while still allowing implementations or > deployments that explicitly opt into non-standard ports to do so via local > policy. > I strongly disagree here. The Web security model is built around the concept of an Origin, which includes the port number. Having one port speak authoritatively on behalf of another is unsafe. I get that you don't have a way around that when it comes to legacy protocols like SOCKS, but you cannot do this safely for HTTPS. If I have a MASQUE server A running on https://masque.uno:4430/ and you go ask my server B at https://masque.uno:443/ anything about server A, it is unsafe to trust B to be authoritative about A. > Minor questions: >>>> > >>>> > * what characters are allowed in the "identifier" string? Is it >>>> encoded as >>>> > ASCII or UTF-8? >>>> >>> >>> Any UTF-8 as per JSON string spec. Clarified in >>> https://github.com/tfpauly/privacy-proxy/pull/316 >>> >>> >> That sounds like it could lead to confusion around escaped characters, as >> mentioned in Section 8.3 of JSON. Wouldn't it be simpler to limit this to >> UTF-8 characters that don't require escaping (see Section 7 of JSON). Or >> perhaps just give guidance by adding a sentence like: "Characters that need >> to be escaped in JSON strings (see Section 7 of JSON) are NOT RECOMMENDED >> because they can lead to difficulties in string comparisons (see Section >> 8.3 of JSON). >> >> > Thank you for your guidance. This is addressed in > https://github.com/tfpauly/privacy-proxy/commit/d7d65f631e8e681a297cf7123d825c982ab2aff0 > (merged into the latest -10 revision of the draft). > > >> draft-ietf-masque-connect-udp-listen deserves its own "protocol" and >>> should be registered in the proposed Proxy Protocol IANA Registry. >>> As draft-ietf-masque-quic-proxy is an optional optimization for >>> connect-udp that is negotiated dynamically. I believe regular "connect-udp" >>> protocol applies. >>> >>> >> Both connect-udp-listen and quic-proxy are negotiated dynamically. But it >> would still be helpful for the PVD to indicate support for them, because >> the client might change its behavior based on knowing what the proxy >> supports. For example, it allows the client to select a better MTU or a >> different WebRTC operation mode before establishing the connect-udp tunnel. >> > > We agree that the advance knowledge of proxy capabilities can influence > client behaviour. > However, the configuration mechanism defined in this document should be > limited to selecting which proxying protocol/mechanism to use, rather than > advertising a potentially open-ended set of optimisations or optional > features within a given protocol. The line we are trying to draw is whether > a proxy technology introduces a new, distinct mechanism that enables new > functionality, as opposed to an optimisation of an existing one. > > From that perspective: > - draft-ietf-masque-connect-udp-listen introduces a materially different > proxying capability (accepting inbound UDP via the proxy) and therefore > merits being identified as a separate proxy protocol and registered as such. > - draft-ietf-masque-quic-proxy is an optimisation layered on top of > CONNECT-UDP rather than a new proxying mechanism > > More generally, we expect additional optimisations and capabilities to > emerge over time (e.g., checksum offload, compression, multipath, > authentication methods). Encoding all such capabilities in PVD > configuration would significantly increase complexity and risk making both > specifications and implementations fragile and difficult to evolve. > The intent is therefore to keep PVD configuration focused on > coarse-grained protocol selection, and rely on in-band negotiation within > the selected protocol for fine-grained capability discovery and > optimisation. > It looks like the text in the draft disagrees with what you wrote here. Tommy suggested having all these set up as optional keys: https://github.com/tfpauly/privacy-proxy/commit/a81ede2460ad8299fcd94b2addb8b5a7eea0c435 For what it's worth, I think I prefer Tommy's approach to punt this to optional keys. The key difference is that "X-" headers did not include a vendor name which >>> resulted in conflicts between implementations. >>> Our design is inspired by SSH namespaces which are reasonably successful >>> at trialing something vendor specific and later dropping the vendor >>> designation if the capability goes mainstream enough. >>> >>> >> Fair enough. If there are two underscores, what's the vendor name? E.g., >> if the key is "aaa_bbb_ccc", is the vendor name "aaa" or "aaa_bbb"? Might >> be worth clarifying if the goal is to avoid conflicts on vendor names. >> > > > Everything in front of the final underscore is treated as the vendor name. > Clarified this in > https://github.com/tfpauly/privacy-proxy/commit/eda2bd52530baa1d9cd634038ed28d76c0a7f130 > (merged into the latest -10 revision of the draft). > > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
