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. > > * 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 > 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 > > > > * 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. Do you think we need to provide additional guidance and "expert review" IANA process is not enough? > > > > * 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. -- 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]
