Thanks for the review Kyle, You likely have already seen these, but for the benefit of the folks in the cheap seats, I've linked to pull requests below. On Fri, Dec 9, 2022, at 09:08, Kyle Rose via Datatracker wrote: > - Section 4 refers to gateways as "servers", presumably copying from existing > HPKE text, which is confusing in the context of the rest of this document. > While a gateway may be co-located on the target server in the typical case, > conceptually it is a separate entity. My recommendation for reader clarity is > to alpha-substitute terminology related to entities in this section to match > the OHTTP model from figure 1. > > - 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 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". > - §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 (And I got your nits, thanks; I always appreciate language pedantism) -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
