Draft: draft-ietf-ohai-ohttp

Commentary: Pretty much what you might expect ; see Section 7.6 of [ HTTP ] .  ? 
 The draft says An Oblivious Gateway Resource , if it receives any response from the Target Resource , sends a single 200 response containing the encapsulated response . What happens if that encapsulated response is zero - length ? The section seems ambiguous on this point . To encapsulate a response the gateway resource needs to hold the private hpke key for every endpoint it services , even if that response is a simple status code with no body content , as is common with POST requests . For security , it would be nice if it were possible to restrict the private key to an offline process . That is , instead of the gateway performing decapsulation itself , it writes the encapsulated request directly to the target and returns success unconditionally . Then a separate process , running in a more restricted environment , performs decapsulation and analysis of the client requests . The attack surface is reduced , and vulnerabilities in the gateway implementation are less serious because it can not leak the keys . One way to do this is to have the gateway return to the relay with no response body , and have the relay forward that back to the client . The client would have to assume success in this case . For some applications , this " best effort " submission could be an acceptable trade off for better data path integrity . 
 The Encapsulated Response encoding currently does not admit a zero - length ( empty ) response . It includes at least max(Nn , Nk)+Nt ( ciphertext tag size ) bytes . This is an interesting use case . I can imagine changing the Encapsulated Response type to admit successful zero - length responses to signal " I received your request and will process it later . " This is n't authenticated any differently from non-2xx responses from the gateway , so I do n't think it 's a problem that the HPKE context is not used to generate the response here . I suppose the main question ( to me ) is whether or not clients should be configured to expect this behavior . What happens if a client gets an empty 200 response when it expected a non - empty response ? Should it retry ? Should it only accept this if the client is configured this way ? The latter is probably doable . thoughts ? 
 I could see allowing it the client has a configuration to handle it specially , but in general , I think that a client would n't expect an empty response that is still a 200 , since it does n't have any expected content type , etc . 
 The encapsulated request and response is effectively just HTTP . IIUC this is a proposal to change the HTTP interaction model to fire - and - forget . I.e. infer that when something on the path claims it delivered something , the client should accept that . Why do we want to change HTTP ? A way to emulate this , without changing HTTP semantics , is to have the  synthesize an encapsulated response itself . Then the client does n't need to handle an empty response . If you cared for signalling , the Gateway could include a field in the synthesized response that indicted this had happened . 
 Agreed with Lucas on this 
 The use case is to hide the private key from the Gateway . Is this possible without access to the key ? 
 I do n't think this is a change to HTTP at all . It 's just a change to the HTTP usage here . It is totally feasible for the relay to return a 200 response to the client that means " I accepted your relay request and will forward it later . " This seems totally valid and indeed something we might want for applications that do n't need a response to the client and want the relay to do some sort of batching . If we wanted to support this , maybe we could use a separate content type for the response that is along the lines of an acknowledgement , rather than a response with actual content . 
 That 's fair . But then we should not be overloading the OHTTP interaction model . Rather , when the  responds with a 200 , it always contains an enclosed response as today . And if you want a different interaction , then return a different status code like : This 202 representation is not the enclosed request - it could be empty . 
 Oh , perfect ! I did n't know 202 existed . That sounds like it would work here without any sort of change , beyond maybe a note saying that it 's possible to use ? 
 Personally I 'd lean more towards being explicit that this could happen , and is effectively a conditional terminal branch of the sequence at step 6 https://ietf - wg- But that 's just my 2c 
 Being explicit makes it more likely this path will be implemented uniformly . 
  the operation of the protocol for a 202 is possible , but I doubt we could do that trivially . A relay can send 202 . This introduces some interesting consequences for end - to - end reliability . A gateway might also send 202 ( it takes the request , stores it , responds ) . The gateway concerns are approximately the same . As observes , this might allow the gateway to operate without the private key , which is a very useful feature for something like STAR . If we deal with this case in this document , we 'll have to cover all bases . I see three options : specify the necessary behaviour here , in full . We describe the general sort of circumstance in which it might be advantageous to have the client not wait around for a full end - to - end response . We explain that the relay / gateway needs to understand the application for which it is forwarding requests and that 202 responses are generally not acceptable . We explain that by responding with 202 the relay / gateway takes responsibility for the forwarding of the request and any necessary actions that might be needed to improve reliability , including retries . We explain that clients that use such a relay / gateway need to be aware of what the relay / gateway might do and that this means that they will not get any end - to - end signal that provides them with a reliable indication that their request was processed . specify a separate extension , with all of the above . leave this extension to each application of the protocol , which can address each of the above points as it chooses . That application can do less about addressing those concerns as it might specify the use of 202 at only one of the nodes . I 'm guessing that this is for STAR , so it does make a degree of sense to have the gateway to store requests and respond with 202 . As a telemetry system , the loss of reliability is essentially zero ( you do n't get an end - to - end confirmation that the key you chose worked , so it 's not perfect , but that 's deliberate and more of a feature than a bug in that case ) . So I 'm inclined to suggest that STAR deal with describing this . 
 Yeah , my concern is that this could be feature creep and delay this document further , when it 's already achieved the starting goals . Punting to another document seems fair to me . What I might expect here is some brief service about how a gateway responds when there is no response from the target . This thread started with the draft excerpt : Ignoring fancy usecases , there are failure cases for the the Gateway : fail to resolve the target , or fail to connect to it , or fail receive a complete response . In other HTTP intermediation , returning a 5xx ( e.g. 502 , 504 ) is common for such cases . If the gateway did that here , I 'm not clear what expectations there on the response - the MUST requirement for the 200 case ca n't apply right ? 
 The MUST there is implicitly conditional on the gateway receiving a response . We can add a sentence saying that if the gateway does n't receive a response it can encapsulate an appropriate error response ( like 504 ) . 
 I 've opened . It does n't address this specific concern , but it will deal with the problem Lucas identified . 
 I threw together describing an unreliable variant of OHTTP that satisfies the use case motivating this issue . ( and others ) , please have a look ! Contributions from everyone are welcome . 
 The unreliable - ohttp draft addresses my motivating use case , and there 's at least some clarifying text about error handling for the Relay , so I 'm satisfied this is addressed .
When a response is received from the Oblivious Gateway Resource, the
Oblivious Relay Resource forwards the response according to the rules
of an HTTP proxy; see HTTP.
When a response is received from the Oblivious Gateway Resource, the
Oblivious Relay Resource forwards the response according to the rules
of an HTTP proxy; see HTTP.  In case of timeout or error, the
Oblivious Relay Resource can generate a response with an appropriate
status code.
An Oblivious Gateway Resource that does not receive a response can
itself generate a response with an appropriate error status code
(such as 504 (Gateway Timeout); see HTTP), which is then encapsulated
in the same way as a successful response.