Hi Tommy and Yaroslav, thanks for the replies - and my apologies for the delayed response. It's been a crazy month. Your PRs address some of my concerns but not all of them. More detailed responses inline below. David
On Thu, Nov 13, 2025 at 6:38 AM Tommy Pauly <[email protected]> wrote: > We’ve published the updates from the PRs referenced below in this > revision: > https://www.ietf.org/archive/id/draft-ietf-intarea-proxy-config-09.html > > Thanks, > Tommy > > On Nov 13, 2025, at 3:53 AM, Yaroslav Rosomakho <[email protected]> > wrote: > > Hi David, > > Thank you very much for the thorough review! > > Please see responses below inline. > > -yaroslav > > > > * what's the status of implementation? Hopefully we have multiple >> > interoperating before sending to the IESG? >> > > Apple has an implementation of both client and server side. Few other > vendors have implementations of the server side. > > Great! > > >> > * why do we restrict the discovery to .well-known/pvd ? I totally get >> > having the well-known path for cases where the proxy is configured via >> > hostname and port (similar to the default URI template for connect-udp), >> > but forcing the path like this prevents having multiple different >> > configurations on the same hostname. I think that's a shame, it prevents >> > one from running the proxy at a specific path while keeping the rest of >> the >> > website open. If we force a separate hostname, we're leaking that to the >> > network in the SNI. >> > >> > * Similarly, I understand forcing the port if the proxy uses a different >> > protocol like SOCKS, but it doesn't make sense to me for HTTPS. I would >> > love to be able to have a full-service HTTPS proxy with all the methods >> and >> > the discovery, all within its own port. >> > > 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. > 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). > * how would you envision advertising support >> > for draft-ietf-masque-connect-udp-listen or >> draft-ietf-masque-quic-proxy in >> > this config? Perhaps some guidance in the document would help designers >> of >> > future extensions to proxying protocols? >> > > 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. Do you think we need to provide additional guidance and "expert review" > IANA process is not enough? > > I feel like I would need that guidance myself, since it's unclear what I'm supposed to do for connect-udp-bind. > * in destination rule domains, do wildcards have to be prefixes? Or is >> > "*.example.*" allowed? >> > > Only prefix wildcards are allowed. Clarified in > https://github.com/tfpauly/privacy-proxy/pull/318 > > >> > >> > * I would also allow vendor-specific entries for Proxy Information PvD >> Keys >> > > This is allowed! Section 3.2 "Proprietary keys in proxy configurations" > > >> > * That said, the vendor-specific carveout reminds me of the "X-" prefix >> in >> > HTTP headers. It was originally intended such that vendor-specific >> choices >> > would use it and they would then transition to a "standard" without the >> > "X-" prefix. In practice, once the header got traction, no one wanted to >> > change it any more so the "X-" value became the standard. That same >> > scenario is likely to happen here, so I would modify the IANA expert >> > requirement to allow underscores if there is wide deployment of the >> entry > > > 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.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
