Replay attack and timestamp

[huitema]

Attackers cannot successfully replay a ClientHello and ESNI extension and establish a connection with the server. However, they can replay a ClientHello and examine whether it triggers a positive response. This can be used to check whether a server is still present. This is a particular concern when using ESNI in local discovery mode, where merely eliciting a response would be enough to give away a server's presence.

To protect against such attacks, I consider adding two elements in the ESNI:

1. A 64 bit timestamp, set to the date at which the client sent the message.
2. The IPv6 address from which the client is sending the message.

The timestamp prevents repeat of a message over time. The IPv6 address prevents repeat of the message from a different location. I mention IPv6 here because of NAT, of course.

What do you think? Should that be encoded as part of ClientEncryptedSNI or ClientESNIInner? Or should it just be encoded as a separate ClientHello extension?

[martinthomson]

I like the timestamp idea. Even if it is only fuzzy. The timestamp seems adequate, because the fact that a server remains active over short timescales is not that interesting - more so if the connection that is being replayed is still active.

For the timestamp, fewer bits will be sufficient as long as the timestamp can express a longer duration than the maximum key validity. 32 bits is plenty, assuming second resolution. 16 might even suffice.

[Lekensteyn]

Frequent ESNIKeys rotation (and subsequent enforcement by the server) should mitigate this issue a bit.

Encoding the time as-is would undo the effect of removing the time from the client random field. Not sure if that is desirable.

What is your attacker's model? Even with a truncated timestamp (e.g. in 1 minute intervals), there is still a time span where the confirmation attack could be executed. And if you are worried about an adversary who is trying to raid a data center and needs to track down a physical machine behind a load balancer, then having the IPv6 address binding would not help since the attacker could just spoof packets.

[ghedo]

How long would the server's "replay window" be in terms of time? If it's less than say, a day, the server would start seeing a lot of spurious failures due to client clock skew.

[davidben]

Likewise the client will observe failures, and these will hit all connections for some small fraction of users, which is much worse than hitting some small fraction of connections for all users.

Is the expectation that the client would fail the connection or retry without ESNI? The latter has a clear downgrade attack, while the former strongly discourages ESNI deployment. I would need to check with folks on what kinds of clock skews are observed, but I expect it would be much much higher than a day.

Now that we have the robustness mechanism (if the server does not recognize ESNI, it just responds based on SNI) is that sufficient to resolve this? The server will respond with something either way, and the attacker can't tell which certificate it was.

[martinthomson]

@davidben has a point about fallback to SNI. If use of the fallback SNI is indistinguishable from successful use of ESNI, then we're good: the observer gains nothing. Is that a requirement we levy on servers though?

[chris-wood]

Hmm, is indistinguishability possible? In the fallback SNI case, the server's EE might carry one or more ESNIKeys, which inflates the size of this message well beyond the EE message size in the normal (non-fallback) case. If we want to make them indistinguishable, we'd probably need to recommend further requirements that the server's EE message(s) are the same in both cases, which is not great.

[martinthomson]

Good point. The extra bits will appear to be part of the certificate chain from the outside. That means potentially padding everything. If that is a problem, could the fallback be made to appear more like a response to a request? That's structurally very different though, and perhaps not worth the pain.

[chris-wood]

@huitema how do you want to proceed here?

[huitema]

I don't think the issue is mitigated yet. The problem is a "discovery oracle", and it is linked to a very specific ESNI usage: broadcast an ESNI on the local network to check whether someone will respond. In the normal case, the response is processed by the node doing the discovery. The issue is that an attacker can replay the message later and see whether the client is still there.

This is not a "mainline" ESNI issue, but just an issue arising from trying to use ESNI in a discovery scenario with Quic or DTLS. It is probably OK to not consider it for the current ESNI design, and to address it in the "discovery scenario" design.

Hence, close with no action.