Cache timing warning

[ekr]

Ben Schwartz writes:

RFC8446 (and bis) currently describe a "cache timing" attack on use of Early Data:

• Exploiting cache timing behavior to discover the content of 0-RTT
  messages by replaying a 0-RTT message to a different cache node
  and then using a separate connection to measure request latency,
  to see if the two requests address the same resource.

In fact, many users of TLS (e.g. HTTPS, DNS-over-TLS) are even more vulnerable to cache-based attacks:

• The attacker can probe the cache without triggering a cache fill (Cache-Control: only-if-cached, RD=0)
• The attacker can observe the remaining cache lifetime, which indicates when cache fill occurred (coincident with the > replay or not), and when a resource will expire out of the cache (best time to try the attack).

I think we should probably broaden the attack description. e.g.

 *  Exploiting cache behavior to discover the content of 0-RTT messages
    by locating a cache node that does not have a resource of interest
   cached, replaying a 0-RTT message to it, and then using a separate
    connection to check if the resource was added to the cache.

I also wonder if we should strengthen the advice about replay defenses.

[davidben]

This isn't strictly specific to 0-RTT. A network attacker can already direct the client's connection to any one cache node and then observe side effects. The main thing enabled by replayability is trying the attack multiple times (up to allowed ticket_age skew) for more reliable signal.

[bemasc]

True, and worth clarifying. A really strong network attacker could even prevent all other access to that cache node, likely giving them several minutes to enumerate different resources, looking for the one the user requested before it expires.

[davidben]

I guess, conversely, a weak network attacker that can see the traffic, but not interfere with it, might not be able to redirect the client's connection, but 0-RTT would enable them to replay it elsewhere.

[ekr]

We're looking at incremental change here. @davidben do you have anything you want to add?

[davidben]

I think past-me was just noting this isn't really 0-RTT-specific. If a user's request has side effects you can observe later, you inherently can observe them. And if those side effects are more interesting if you target a particular server instance you use, a network attacker can always direct you traffic there. From what I can see, what's specific to 0-RTT is just:

• Less capable network attackers may be able to mount this attack. (Redirecting traffic requires some ability to intercept traffic, while just replaying an extra copy only requires you to observe it.)
• 0-RTT replay allows you to repeat the attack on the same input, which might refine any probabilistic aspects of the attack.

Not sure what implications this has on text. Perhaps something like...

• Amplifying existing information leaks caused by side effects like
  caching. An attacker could learn information about the content of a
  0-RTT message by replaying it to some cache node that has not cached
  some resource of interest, and then using a separate connection to check
  whether that resource has been added to the cache. This could be repeated
  with different cache nodes as often as the 0-RTT message is replayable.