Re: [Ohai] Robert Wilton's No Objection on draft-ietf-ohai-svcb-config-06: (with COMMENT)

[Tommy Pauly <[e-mail]>]

> On Oct 6, 2023, at 6:14 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Tommy,
> 
> Please see inline ...
> 
>> -----Original Message-----
>> From: Tommy Pauly <[e-mail] <mailto:[e-mail]>>
>> Sent: Thursday, October 5, 2023 11:18 PM
>> To: Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>
>> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; ohai-
>> [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Shivan Kaul Sahib
>> <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: Robert Wilton's No Objection on draft-ietf-ohai-svcb-config-06:
>> (with COMMENT)
>> 
>> Hi Rob!
>> 
>> Thanks for the review. Response inline.
>> 
>> Best,
>> Tommy
>> 
>>> On Oct 2, 2023, at 3:30 AM, Robert Wilton via Datatracker
>> <[e-mail]> wrote:
>>> 
>>> Robert Wilton has entered the following ballot position for
>>> draft-ietf-ohai-svcb-config-06: No Objection
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
>> ballot-positions/
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-ohai-svcb-config/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Hi,
>>> 
>>> Thanks for this document.  I have one minor level:
>>> 
>>> (1) p 7, sec 7.  Security and Privacy Considerations
>>> 
>>> Is another security/privacy consideration here that the target service (since
>>> it is collocated with the gateway) potentially has knowledge about whether
>> the
>>> request is coming via a OHTTP gateway and hence may offer a different
>> service
>>> to those clients connected via the OHTTP gateway vs those clients that are
>>> directly connected?  For example, if the target server is a DNS resolver, then
>>> perhaps that DNS resolver doesn't resolve requests for some domains when
>>> offering service via an oblivious gateway.
>> 
>> From my understanding, this is a case that would exist for any use of oblivious
>> HTTP (or any proxy, or VPN, etc). There isn't any expectation that an OHTTP
>> gateway would be put in front of a target that isn't cooperating or aware of the
>> gateway, and it could differentiate traffic that comes through a gateway (if it is
>> not co-located) from traffic that isn't coming in over an OHTTP path or another
>> proxied path.
>> 
>> As such, I'm not sure it makes sense to add any text for this particular
>> document?
> [Rob Wilton (rwilton)] 
> 
> This is just a comment (not a discuss) and so I'll leave it entire to the authors/WG to decide whether they want to act on it.
> 
> I guess that the potential difference that I perceived is the discoverability aspect.
> 
> Before, without discoverability, there is presumably a business relationship between the relay, proxy, and target service such that it seems that differentiated behaviour would seem less likely to happen.
> 
> But with this draft, it seems plausible that a target service can offer and advertise "optimistic obliviousness", and without the business relationship, it seems more plausible (at least to me) that this could cause differentiated services in a way that a client probably wouldn't be able to easily detect.

One of the (important) restrictions that we have for the discovery path is that the gateway and the target MUST be co-located on a host, to ensure they’re covered by the same trust/certs, and so you can’t just throw up an arbitrary gateway in front of a non-cooperating server. (I get that’s also the thing that you’re pointing out could allow that one host to differentiate it!)

Based on that, while there may not be a business relationship between the relays and gateways/targets, the gateways and targets are inherently cooperating. I believe a gateway+target that wants to differentiate its service could do so for any case where it allows both oblivious and non-oblivious traffic, regardless of discovery.

> 
> Whether this is worth documenting or not I will leave up to you.

If others in the WG have suggestions for something they’d like to see written here, happy to see PRs, btw!

Tommy
> 
> Regards,
> Rob
> 
> 
>>> 
>>> Regards,
>>> Rob