You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
Both OHTTP's evolution mechanism (media types) and SVCB records' mechansisms
(adding new protocol names such as h2/h3) are availble.
Security
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.
The text was updated successfully, but these errors were encountered: