Re: [Ohai] Working Group Last Call for draft-ietf-ohai-svcb-config

[Tommy Pauly <[e-mail]>]

Hi Shivan, all,

We’ve published a new version now that the last issue/PR is resolved.

Thanks,
Tommy

> On Jun 16, 2023, at 2:26 PM, Shivan Kaul Sahib <[e-mail]> wrote:
> 
> Hi all, thanks for the review and discussion. The chairs think there is consensus to advance this document -- there were several statements of support and no objections. I'll note that there is one open issue, https://github.com/ietf-wg-ohai/draft-ohai-svcb-config/issues/42 which is still being discussed at https://github.com/ietf-wg-ohai/draft-ohai-svcb-config/pull/46. We'll need a new draft version once we agree on the text.
> 
> On Thu, 8 Jun 2023 at 20:24, Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>> Thanks for that clarification. To track this, I’ve filed https://github.com/ietf-wg-ohai/draft-ohai-svcb-config/issues/39, and I’ve opened a pull request to address this here: https://github.com/ietf-wg-ohai/draft-ohai-svcb-config/pull/40.
>> 
>> Please review and provide suggestions!
>> 
>> Best,
>> Tommy
>> 
>>> On May 26, 2023, at 3:35 AM, Martin Thomson <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> On Thu, May 25, 2023, at 19:08, Tommy Pauly wrote:
>>>> To clarify, what specifically were you suggesting that the draft should 
>>>> be explicit about with a MUST? Would that be telling the client to 
>>>> always request the well-known and follow the redirect each time, thus 
>>>> treating even permanent redirects as temporary? I think that is 
>>>> reasonable as a performance loss, given that the client won’t look up 
>>>> the key configuration for each request, but will be able to reuse the 
>>>> configuration as long as it is valid.
>>> 
>>> Good questions.  This probably needs a little unpacking.  (I composed the original on my phone, but I have a real keyboard now.)
>>> 
>>> We have a single resource at /.well-known/ohttp-gateway that performs two functions: the retrieval of a key configuration and oblivious requests.  For the stated reasons, it might be nice if that could redirect to somewhere else.
>>> 
>>> For retrieval of key configurations, I agree that an extra query is workable.
>>> 
>>> It is the oblivious requests that concern me.  Here, the URL is really only something that is used by the relay.  So maybe there is an answer there that relates to the operation of a relay.  This might even be something the core specification could use.
>>> 
>>> This won't be a pre-arranged setup, so we can't start by assuming that the relay knows the gateway URL.  Therefore, the client is telling the relay about the gateway somehow.  If the client says "example.com <http://example.com/>" (without a path) and the relay fills in the well-known path, that is mostly fine as far as tracking the client goes[1].  The client might provide a full URL to the gateway, but uses the well-known URL, with identical effect.  Telling the relay about a redirected URL invites targeting though, especially if the original fetch was not made using a proxy.  308 -> https://gateway.example/your.ip.address.here might not meet our privacy goals.  If the client remembers the redirected path from its key configuration fetch, then the gateway is potentially able to link requests, so we might MUST NOT something about that.
>>> 
>>> For oblivious requests like this, the nice thing is that the relay is in a position to follow and remember redirects for all clients.  The first client to access that gateway through the relay might suffer an extra round trip, but subsequent requests can use the redirected location (let us say that the redirect is a 308).  That is probably something that we could note in the main spec as well or instead.
>>> 
>>> [1] 'unique-id-for-client.example' remains a tiny bit of a concern, but the relay can maybe be relied upon to help detect that sort of badness and we are able to rely on DNS caching... to some extent.
>>> 
>>> -- 
>>> Ohai mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/ohai
>> 
>> -- 
>> Ohai mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ohai
> -- 
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai