On Sat, Dec 10, 2022, at 06:34, Kyle Rose wrote: >> I've also added the shorthand terms to the definitions, though I've avoided using them for the most part. It's more verbose, but consistency is the hobgoblin friend of those looking to make things clearer. > > I'm of course trying to fit OHTTP into my existing mental model for > things like AMT and various VPN tunnel protocols that use "relay" and > "gateway" in the same basic sense when the focus is on the payload > being received, encapsulated, transmitted, decapsulated, and delivered. Ah, yes, that sort of consistency is the reason we're never going to be able to define something free from associations with similar, but distinct things. There just aren't enough words in the language to cover all the potential theme variations. See also packet vs. frame vs. segment... > 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). >> I've attempted a rewording of this here: https://github.com/ietf-wg-ohai/oblivious-http/pull/227 It's not perfect, but I think that avoids the obvious error regarding "before". > > (For reference, the proposed phrasing in the PR is now "unless it is > responding to errors that do not relate to processing the contents of > the encapsulated request".) [...] > - Replies to errors in the envelope request from the relay must be > bare. (easy: the target is the relay, not the client) > - Replies to anything that prevents the gateway from encrypting a > message to the client must be bare. (easy: no choice) > - Replies to any error reported by the target server in the reply to a > delivered decapsulated request must be encapsulated. (easy, I think**) > - Replies to unanticipated server errors (e.g., in constructing (?) or > delivering the decapsulated request)....?? (hard) > > Does this cover everything? If so, the last one is probably where most > of the uncertainty I have lies: the gateway has either successfully > unwrapped the encapsulated request (or could have but didn't quite > yet), but hijinks ensue (code error, bit flip from cosmic ray, target > server hangs up, etc.) and it's unclear to me whether the error should > be revealed to the relay or not. If the design choice is to err on the > side of "tell the relay nothing it doesn't need to know" (something > that seems entirely reasonable for such a protocol), then maybe the > right phrasing here is "unless the outer request cannot be processed or > the encapsulated request cannot have encapsulation removed" (or > preferably something less awkward than that formulation). 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? > The penultimate case ("**") I'm a tiny bit uncertain about, only > because the gateway might add a header or two that could be the trigger > for an error; but this is strictly easier to deal with than the last > case, especially if the heuristic is to reveal as little to the relay > as possible. That seems easy to me. Even if the gateway does something to the request that causes it to fail, it would still be worth encapsulating the resulting response. That action might depend on the content of the encapsulated request, which might lead to a leak of data to the relay. > (For reference, the proposed phrasing in the PR now includes "so > clients might need to use other means of ensuring that unsecured > requests are not exposed to attack.") > > 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. That said, the sort of deployment scenario this protocol envisages does often include control that might allow that to be known. Let's say that Mozilla wanted to use OHTTP for collecting telemetry that might be slightly sensitive. We would deploy the gateway and target resources in our infrastructure, then seek a partner that would operate a relay. In that scenario, as someone building a client (a browser), we'd have a lot of control over the deployment setup on the server end. It wouldn't take much to be confident that the server infrastructure isn't sending requests in the clear in that setup. Of course, there is a version of this architecture that places less trust in the gateway relative to the target. Take the case where the gateway is operated independent of the target. However, that ends up being very much analogous to the relationship between origin servers and CDNs (to the early point about bad analogies being quite accurate up to a point). Maybe I don't need to spell this out, but ... In the CDN case, a client needs to trust that the CDN doesn't send their request in the clear to the origin. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
