| Hi Christian,
Thanks very much for the thoughtful review! Apologies for the late response.
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 <noreply@xxxxxxxx> 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
Ohai@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ohai
|
