Thanks for the quick reply, Martin. Follow-ups inline:
On Thu, Dec 8, 2022 at 8:30 PM Martin Thomson <mt@xxxxxxxxxxxxxx> wrote:
On Fri, Dec 9, 2022, at 09:08, Kyle Rose via Datatracker wrote:
> - The document might also benefit from explicitly introducing "relay",
> "gateway", and "server" as shorthand for "Oblivious Relay Resource", "Oblivious
> Gateway Resource", and "Target Resource", respectively, but not if the given
> verbosity is customary for work in the HTTP ecosystem.
This bit remains under debate, but I definitely agree with you about the text in Section 4, which this changes: https://github.com/ietf-wg-ohai/oblivious-http/pull/225
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. 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?
> I don't think "before removing encapsulation of the request" is quite right.
> The gateway must respond without encapsulation under two conditions: when
> decapsulation of the request fails for whatever reason, or when a
> gateway-generated response is directed at the relay rather than at the
> client. The combination of the two may be what you meant by "before", but I
> would phrase this in a way that doesn't refer to the relative timing of
> gateway actions that could be implemented in an order unanticipated by the
> draft authors and yet still comply with the normative language of the draft.
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".)
This is closer. I've rewritten this paragraph a few times because the more I think about it, the happier (maybe too strong; "finer"?) I feel about what you've proposed, so now I'm trying to think through the various cases systematically:
- 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).
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.
> - §6.3 states "Nonsecure requests...SHOULD NOT be used if the Oblivious Gateway
> and Target Resources are operated by different entities". Unless "entity" has
> some specific term-of-art meaning in this context, I think this needs to be
> strengthened. My company, for example, is an entity that operates servers
> globally, but we should still not use plaintext HTTP between gateways and
> servers separated by the public internet.
This is a useful observation. My original position was that we shouldn't allow "http", but I was ultimately convinced to put this text in: after all, this protocol allows us to secure a resource that isn't natively protected. The text I'm proposing here says "same origin" rather than the vague "same entity", but further acknowledges the possibility that that might not be enough and (unspecified) other checks might be needed.
See https://github.com/ietf-wg-ohai/oblivious-http/pull/228
(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? The client is putting a significant amount of trust in the gateway, both in general and specifically for use cases for which OHTTP is appropriate. In general, the gateway could selectively drop requests; and specific to OHTTP, it seems difficult (and maybe impossible) to square something like client-originated authenticated integrity protection with the desire for anonymity. I wonder whether it makes sense to discuss the limits of protection possible within the bounds of what the scheme is trying to achieve, but that might be far too big a rathole to consider for this particular document.
Kyle
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
