Change:
This includes the time correction piece. I'm interested in whether people think that it is OK to include that. The section could be removed along with the corresponding IANA piece, but given the prevalence of clock skew, I'm inclined to leave it in.
The picture might help, but it is also a lot of vertical real estate to dedicate to this. Let's see if I can't compress it a little.
Maybe an alternative style is to just list the happy path actions in a list? Client sends request, gets back response with 4xx and date header, retires request with new HPKE context, and then stops based on response, or something. These four simple steps are just spread across a lot of lines right now. But this is purely editorial, so I trust your judgement here.
There is a bunch of stuff that we normatively depend on regarding the use of Date. As it seems like request-date isn't going anywhere, we should pull in the relevant pieces instead.
That sounds reasonable like a reasonable way to unblock us and make forward progress.
Addressed by .
This LGTM. I wonder if it would be helpful to show the retry dance in a picture. Something like:

Discussion:
amount of requests it needs to track if it needs to prevent replay attacks. <del> A server can maintain state for requests for a small window of time over which it wishes to accept requests.  The server then rejects requests if the request is the same as one that was previously answered within that time window.  Servers can reject requests outside of this window and signal that clients might retry with a different "Date" header field; see REQUEST-DATE.  Servers can identify duplicate requests using the encapsulation ("enc") value. Servers SHOULD allow for the time it takes requests to arrive from the client, with a time window that is large enough to allow for differences in the clock of clients and servers.  How large a time window is needed could depend on the population of clients that the server needs to serve. Servers MUST NOT treat the time window as secret information.  An attacker can actively probe the server with specially crafted request timestamps to determine the time window over which the server will accept responses. REQUEST-DATE contains further considerations for the use of the "Date" request header field.  This includes the way in which clients might correct for clock skew and the privacy considerations arising from that usage.  Servers that reject requests on the basis of the "Date" request header field SHOULD implement the feedback mechanism in REQUEST-DATE to support clock correction by clients. </del> <ins> An Oblivious Gateway Resource can maintain state for requests for a small window of time over which it wishes to accept requests.  The Oblivious Gateway Resource can store all requests it processes within this window.  Storing just the "enc" field of a request, which should be unique to each request, is sufficient.  The Oblivious Gateway Resource then rejects requests if the request is the same as one that was previously answered within that time window, or if the "Date" header field from the decrypted request is outside of the current time window. Oblivious Gateway Resources SHOULD allow for the time it takes requests to arrive from the client, with a time window that is large enough to allow for differences in clocks. Oblivious Gateway Resources MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to determine the time window over which the server will accept responses. 7.4.2. An Oblivious Gateway Resource can reject requests that contain a "Date" value that is outside of its active window with a 400 series status code.  The problem type PROBLEM of "https://iana.org/assignments/http-problem-types#date" is defined to allow the server to signal that the "Date" value in the request was unacceptable. fig-date-reject shows an example response in HTTP/1.1 format. Disagreements about time are unlikely if both client and Oblivious Gateway Resource have a good source of time; see NTP.  However, clock differences are known to be commonplace; see Section 7.1 of CLOCKSKEW. Including a "Date" header field in the response allows the client to correct clock errors by retrying the same request using the value of the "Date" field provided by the Oblivious Gateway Resource.  The value of the "Date" field can be copied if the request is fresh, with an adjustment based on the "Age" field otherwise.  When retrying a request, the client MUST create a fresh encryption of the modified request, using a new HPKE context. Intermediaries can sometimes rewrite the "Date" field when forwarding responses.  This might cause problems if the Oblivious Gateway Resource and intermediary clocks differ by enough to cause the retry to be rejected.  Therefore, clients MUST NOT retry a request with an adjusted date more than once. Oblivious Gateway Resources that condition their responses on the "Date" header field SHOULD either ensure that intermediaries do not cache responses (by including a "Cache-Control" directive of "no- store") or designate the response as conditional on the value of the "Date" request header field (by including the token "date" in a "Vary" header field). Clients MUST NOT use the date provided by the Oblivious Gateway Resource for any other purpose, including future requests to any resource.  Any request that uses information provided by the Oblivious Gateway Resource might be correlated using that information. </ins> 7.5.

The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <ins> 7.7. Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or to identify clients that are vulnerable to attacks that depend on incorrect clocks. Clients can randomize the value that they provide for "Date" to obscure the true value of their clock and reduce the chance of linking of requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window. </ins> 8. One goal of this design is that independent client requests are only

11. <del> Please update the "Media Types" registry at </del> <ins> IANA are request to update the "Media Types" registry at </ins> https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. </ins> 12.  References 12.1.  URIs