Draft: draft-ietf-ohai-ohttp

Commentary: 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 ca n'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 is n'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 :
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.
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.
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.
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.
Please update the "Media Types" registry at
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".
IANA are request to update the "Media Types" registry at
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".
IANA are requested to create a new entry in the "HTTP Problem Type"
registry established by PROBLEM.