Subject: [Ohai] Using Date for anti-replay

From: "Martin Thomson" <[email-masked]>
Date: Mon, 17 Jan 2022 12:46:44 +1100

In various issues [1] we've been discussing the ways in which a server might protect itself from replay attack.

Servers have to trust that proxies don't do certain things, like DoS.  That doesn't extend to anti-replay.  The effect of a replay for some types of request is limited enough that specific anti-replay is not necessary [2].  For other forms of request, servers might benefit from some sort of anti-replay protection.

Preventing anti-replay generally depends on remembering requests, which can lead to a lot of state for a server.  One way in which this can be managed is by having a timestamp in requests.  Servers can then remember requests in a narrow window around the current time and reject all other requests.  This allows the server to limit how much state it holds to a number based on the size of the window and the rate of requests it is willing to accept.

To support this approach, we toyed with a specific timestamp field in the message [3].  That complicated things too much and we decided to look to HTTP instead.  It seems like the HTTP Date header field is almost perfect.  It's optional, well-defined, and easy to integrate.  The drawbacks are that it's syntax is arcane and its use in requests is mildly discouraged.  I don't think that discouragement is a deal-breaker in this context, so on balance it seems right.

Q1: Is setting the HTTP Date header field on requests a good (or acceptable) way to help servers manage state for anti-replay?

The most obvious problem with Date, as with any value from the clock, is that it can be wrong.  In fact, it very often is wrong.  Badly [4].  That leads me to ask how we might correct that problem.

Now, HTTP responses often include a Date header field in the response.  If the server were to indicate somehow that the Date in the request was badly skewed, maybe the client could use the server's Date to correct their own clock.  That's not roughtime [5] or even tlsdate [6], but it has similar characteristics in terms of reliability and accuracy.

The idea here would not be to use this to synchronize the clock.  This server might be "trusted" to answer a certain request, but unless the client has configured it as a time source, the time it claims to have is not fit to be used more broadly.  Indeed, a malicious server might use this to track users, providing each with a unique time in order to unmask future requests.  That means that the date provided, if used, would link requests.  Thus, the client might only retry a request with the date adjustment, not use it for any other request.  A server would them be able to link those two requests using the date, but nothing else.

In order to engage that logic, we would need some sort of indicator in a response.  My thought is that this is likely necessary, and maybe it is even useful for other reasons.  I would like to ask the HTTP working group for input on the best way to create that signal.

Q2: Should we ask the HTTP working group for help in building a mechanism for correcting the time (or Date) in a request?

This is one of the larger open questions I have with the drafts right now [7].

Cheers,
Martin

[1] https://github.com/ietf-wg-ohai/oblivious-http/issues/76

[2] Replay of simple queries can be indistinguishable if there are no side-effects or processing is identical.  This doesn't necessarily work for something like DoH, which might reveal the effect of a query on the cache at a recursive resolver.  Whether that potential exposure means building anti-replay infrastructure might depend on how clients and servers regard the effect of that risk.  

[3] https://github.com/ietf-wg-ohai/oblivious-http/pull/88 - probably not accepting this one.

[4] Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors, Section 7.1 <https://dl.acm.org/doi/10.1145/3133956.3134007>

[5] draft-ietf-ntp-roughtime-05

[6] https://github.com/ioerror/tlsdate

[7] https://github.com/ietf-wg-ohai/oblivious-http/issues/89

---

From: Christopher Wood <[email-masked]>
Date: Thu, 20 Jan 2022 09:35:45 -0800

Sorry for the delay here, Martin, and thanks for writing this up. Please see inline below.

> On Jan 16, 2022, at 5:46 PM, Martin Thomson <[email-masked]> wrote:
> 

As in the original proposal [3], would the idea for this header to be mandatory, or simply recommended? As you say, it’s ultimately up to the client and server to determine if the risk of replay is worth the added complexity here. I think it would be reasonable to recommend this for certain applications using OHTTP, perhaps along with the retry mechanism you hint at below to make this usable given client clock skew.

> Q2: Should we ask the HTTP working group for help in building a mechanism for correcting the time (or Date) in a request?

To clarify, would the interaction here would be something like the following (ignoring the layer of encapsulation)?

C->S: GET /, Date=T
S->C: 4xx, Date=T’
C->S: GET /, Date=T’
S->C: 200

This is the same basic robustness design we use for ECH, and applying the pattern here seems appropriate given the problem (client and server disagree on something, in this case Date, and in the ECH case the ECHConfig). Asking the HTTP WG for help in designing this mechanism seems like a good step forward.

Best,
Chris

> -- 
> Ohai mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ohai

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Jan 2022 11:02:21 +1100

> On 21 Jan 2022, at 4:35 am, Christopher Wood <[email-masked]> wrote:
> 

If so, one hiccup might be that it's not uncommon for intermediaries (especially CDNs) to rewrite Date in responses to the current time; see discussion in the TCC draft.

Of course, CDNs can be updated to stop that in a specific scenario, but if a UA and origin want to use this method through such an intermediary without its participation, that'd be a problem. So it might be safer to use a header other than Date S->C.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 21 Jan 2022 11:15:11 +1100

On Fri, Jan 21, 2022, at 11:02, Mark Nottingham wrote:
> If so, one hiccup might be that it's not uncommon for intermediaries 
> (especially CDNs) to rewrite Date in responses to the current time; see 
> discussion in the TCC draft.

This is only a problem when a CDN is handling the cleartext portion of the request.  So in common deployment scenarios where the oblivious request resource (the one that removes encryption) and the oblivious target resource (the one that handles the request) are co-hosted, there is unlikely to be an intermediary interposed.

> Of course, CDNs can be updated to stop that in a specific scenario, but 
> if a UA and origin want to use this method through such an intermediary 
> without its participation, that'd be a problem. So it might be safer to 
> use a header other than Date S->C.

It is not strictly a problem if the CDN rewrites Date on the S->C direction as long as the CDN clock is not *badly* out of sync with the ultimate server.  As long as the client gets a vaguely correct time, things will be back on track.

We're just looking to prime the client with a Date (or time really) that isn't off by too much.  "Too much" is probably measured in minutes, in this case given various constraints.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 21 Jan 2022 11:19:14 +1100

On Fri, Jan 21, 2022, at 04:35, Christopher Wood wrote:
> As in the original proposal [3], would the idea for this header to be 
> mandatory, or simply recommended? 

I would look to recommend only, yeah.  Of course, the correction scheme (below) could be used to tell clients that omit Date to try another request with a Date included.

> To clarify, would the interaction here would be something like the 
> following (ignoring the layer of encapsulation)?
>
> C->S: GET /, Date=T
> S->C: 4xx, Date=T’
> C->S: GET /, Date=T’
> S->C: 200

That's the idea, yes. Minor tweaks to T' might account for any elapsed time (adding half an RTT might do it).

---

From: Christopher Wood <[email-masked]>
Date: Fri, 21 Jan 2022 19:19:04 -0800

> On Jan 20, 2022, at 4:19 PM, Martin Thomson <[email-masked]> wrote:
> 

Yep, that makes sense to me. Unless you’ve already started, I’ll put up a proposal to address #89 (and related issues).

> That's the idea, yes. Minor tweaks to T' might account for any elapsed time (adding half an RTT might do it).

Cool — thanks for confirming.

Best,
Chris