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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
