Section 6.4

[martinthomson]

Comment by @paulwouters

In Section 6.4

Clients SHOULD include a Date header field in Encapsulated Requests, unless the Oblivious Gateway Resource does not use Date for anti-replay purposes. 

How does a client know this? Preconfiguration ?

Oblivious Gateway Resources might need to 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.

Are we talking ms? sec? minutes? Any advise to implementers ?

[martinthomson]

Are we talking ms? sec? minutes? Any advise to implementers ?

It can't be less than 2s, because the granularity of the Date field doesn't permit detecting anything finer than 1s.

I've done what I can.

[paulwouters]

This still does not seem to address:

Clients SHOULD include a Date header field in Encapsulated Requests, unless the Oblivious Gateway Resource does not use Date for anti-replay purposes.

Maybe just cut off the “unless” part if there is no signal for this?

Paul

[martinthomson]

@paulwouters, #263 also included https://github.com/ietf-wg-ohai/oblivious-http/pull/263/commits/1529f5dc5be22fceb94b07942fcf724c95406f5e which I think should address your concern:

 Clients SHOULD include a `Date` header field in Encapsulated Requests, unless
-the Oblivious Gateway Resource does not use `Date` for anti-replay purposes.
+the Client has prior knowledge that indicates that the Oblivious Gateway
+Resource does not use `Date` for anti-replay purposes.

[paulwouters]

Thanks. That commit does address the issue, mostly. I guess it moves it do an unspecified provisioning layer :P

Paul