Re: [Ohai] Artart last call review of draft-ietf-ohai-svcb-config-05

[Tommy Pauly <[e-mail]>]

Hi Christian,

Thanks very much for the thoughtful review! Apologies for the late response.

I’ve opened the following PR: https://github.com/ietf-wg-ohai/draft-ohai-svcb-config/pull/54

In addition to addressing the editorial remarks, I’ve adjusted the text around key configuration fetching to move the considerations for direct vs proxied up front. I do think it makes sense to highlight this earlier, since most implementations will want to proxy and/or use consistency checks. I don’t think it’s necessary, or even the right approach, to define an extension to the Oblivious Relay behavior to take on the role of proxy here. While it may serve as the entity that can fetch these configurations, the client could also have some other proxy that serves the same purpose. Additionally, it may not be necessary to proxy the fetch at all if the client is not concerned with communicating to the gateway — but only concerned about linking its particular request content to its identity; in such cases, a consistency check alone is sufficient.

Best,
Tommy

> On Aug 21, 2023, at 12:09 PM, Christian Amsüss via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Christian Amsüss
> Review result: Ready with Nits
> 
> Summary
> =======
> 
> This document fixes a gap between OHTTP servers and clients that was previously
> only addressed by out-of-band configuration. Apart from one security note
> (that's more on the how-do-we-get-it-implemented-well side and not on the
> there-is-a-flaw side), I think this is in very good shape.
> 
> Typical ART Area Issues
> =======================
> 
> * The document does not provide individual extension points, but that is OK:
>  Both OHTTP's evolution mechanism (media types) and SVCB records' mechansisms
>  (adding new protocol names such as h2/h3) are availble.
> 
> Security
> ========
> 
> * Key configuration fetching: This introduces a direct HTTP request from the
>  client to the Gateway, which with my limited overview of OHTTP is a new leg,
>  and reveals to the gateway an IP address from which it will be accessed (even
>  though the rules in section 5 on of not telling the relay where
>  .well-known/ohttp-gateway redirected will make sure that request can't be
>  correlated with the later OHTTP requests trivially). It does hint at using a
>  proxy (with later remarks in sec-cons pointing to a possible solution), but I
>  think it'd make sense to explore that option more thoroughly.
> 
>  It's hard for this document to mandate that those requests be proxied through
>  the relay (which doesn't generally do HTTP style proxying, and could be
>  limited to allow-listed requests such as GET /.well-known/ohttp-gateway
>  accepting application/http-keys), but unless that has been gone through in
>  previous discussions (in which case I'd appreciate a pointer), I think it'd
>  make sense to make that a default operation, falling back to direct GETs only
>  if the relay happens to not support that operation.
> 
>  If this is just done to avoid a normative reference to the comparatively
>  young CONSISTENCY document, maybe it'd be worth the wait. I haven't gone
>  through that complete document, it seems to offer several approaches. It may
>  not be possible to pick one that's good for all purposes, but if any of them
>  need collaboration from the relay, it'd be helpful if implementers took good
>  note that more is expected and needed of relays now.
> 
> Editorial remarks
> =================
> 
> * "an Oblivious Gateway Resource (gateway), which gates access to the target.":
>  I'd read that as limiting who may access the target, which to my
>  understanding is not the case. Maybe "which offers Oblivious HTTP accesst to
>  the target"?
> 
> * 'he "ohttp" SvcParamKey (Section 8) is used': I think that the forward
>  reference into IANA considerations is more confusing than helpful. This key
>  is defined here, IANA considerations just contain instructions to make it
>  happen in the registries. A reference back up (from table 8.1, s/This
>  document/This document (Section 4)/) would make more sense.
> 
> 
> 
> -- 
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai