Similar to the earlier discussion on 0.5-RTT data, I'm concerned with the long
term ability to replay captured 0-RTT early data, and the attack vectors that
it opens up. For example, take a GET request for an image to a CDN. This is a
request that seems completely idempotent, and that applications will surely
want to send as 0-RTT data. However, this request can result in a few things
happening:
1) Resource unavailable
2) Resource cached locally at edge cluster
3) Cache miss, resource must be fetched from origin data center
#1 can easily be differentiated by the length of the 0.5-RTT response data,
allowing an attacker to determine when a resource has been deleted/modified. #2
and #3 can also be easily differentiated by the timing of the response. This
opens up the following attack: if an attacker knows a client has requested a
resource X_i in the attacker-known set {X_1, X_2, ..., X_n}, an attacker can do
the following:
1) wait for the CDN cache to be evicted
2) request {X_1, X_2, ..., X_(n/2)} to warm the cache
3) replay the captured client early data (the request for X_i)
4) determine, based on the timing of the response, whether it resulted in a
cache hit or miss
5) repeat with set {X_1, X_2, ..., X_(n/2)} or {X_(n/2 + 1), X_(n/2 + 2),
..., X_n} depending on the result
This particular binary search example is a little contrived and requires that
no-one else is requesting any resource in the set, however I think it is
representative of a significant new attack vector that allowing long-term
replay of captured early data will open up, even if 0-RTT is only used for
seemingly simple requests without TLS client authentication. This is a much
different threat than very short-term replay, which is already somewhat
possible on any TLS protocol if clients retry failed requests.
Given this, I think it is worth attempting to limit the time frame that
captured early data is useful to an attacker. This obviously doesn't prevent
replay, but it can mitigate a lot of attacks that long-term replay would open
up. This can be done by including a client time stamp along with early data, so
that servers can choose to either ignore the early data, or to delay the
0.5-RTT response to 1.5-RTT if the time stamp is far off. This cuts down the
time from days (until the server config/session ticket key is rotated) to
minutes or seconds.
Including the client time also makes a client random strike register possible
without requiring an unreasonably large amount of server-side state.
I am aware that client time had previously been removed from the client random,
primarily due to fingerprinting concerns, however these concerns can be
mitigated by
1) clients can choose to not include their time (or to include a random time),
with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visible
to eavesdroppers
Note: it's also useful for the server to know which edge cluster the early data
was intended for, however this is already possible in the current draft. In
ECDHE 0-RTT server configs can be segmented by cluster, and with tickets, the
server can store cluster information in the opaque ticket.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
