And, time flies... On Sun, Dec 11, 2022 at 7:58 PM Martin Thomson <mt@xxxxxxxxxxxxxx> wrote: > > The way I'm reading the difficulty here is that whereas "relay" and > > "gateway" may imply characteristics unintended by the draft, such as > > having distinct IP addresses or DNS names, a "resource" is a basic unit > > of functionality in the HTTP ecosystem, and is identified by a URL, and > > implies nothing about (for instance) being 1:1 with origins or > > processes or being an isolated network element. Is that right, or is > > the concern something else? > > Yeah, the resemblance to those other things is useful at the most abstract level, but it can create confusion if you expect things to match more closely. As you say, the use of "Resource" - in the HTTP sense - is somewhat critical here, which is why the draft is somewhat meticulous about its use. > > It probably doesn't need to be so strict: we routinely refer to them in discussions as simply "relay" or "gateway". However, as you have observed, if you think of these things as more closely analogous to something else with a similar name - like a TURN relay or a VPN gateway - you end up drawing some conclusions that can be shockingly close to correct, but maybe still wrong if you take the analogy too far (identification: yes; identification with a DNS name: less so). That's reasonable. Discouraging folks from bringing their existing mental models to OHTTP, or at least implying they ought to think about how well they apply, is probably desirable here. > That's definitely the principle that applied to the "before" that was there in previous iterations. > > I've just pushed a change to say "unless it relates to errors in the processing of the unprotected request from the Oblivious Relay Resource, including removing encapsulation". Does that work better? I think that covers it. > > Is such a thing even within the client's control? > > If it is not, then maybe consider using "https" :) That's what this is really saying. I was looking at this from the standpoint of naïve client control, when really the analysis needs to begin from the standpoint of the client assuming trust in the target: without that, all bets are off. But if the client trusts the target, then assuming there is at minimum a relationship between the target provider and the gateway provider, presumably any privacy-compromising ingress from a relay will be prohibited. If this isn't spelled out anywhere in privacy considerations (didn't see anything in a quick scan), I think this would help close the loop for people not steeped in OHTTP. While I'm leaning toward this kind of thing belonging on the "privacy" side of the security/privacy considerations divide, it might also be appropriate to mention under "Server Responsibilities". Anyway, IMO this is basically good to go! Good stuff, and well written. Thanks, Kyle -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
