Re: [TLS] Limiting replay time frame of 0-RTT data

Hi Kyle,

In my talk at TRON, I was also concerned by potential attacks from allowing 
unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
implement replay protection using a cache, but requiring clients to provide
a timestamp in the client random is a great idea. Perhaps this would also
allow TLS 1.3 servers to detect clients whose clocks are too out-of-sync with
the server (and hence vulnerable to expired certificates)?

Best,
Karthik

> On 12 Mar 2016, at 13:56, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Hi Kyle,
> 
> Clever attack. I don't think it would be unreasonable to put a low granularity time stamp in the
> ClientHello (and as you observe, if we just define it it can be done backward compatibly)
> or as you suggest, in an encrypted block. With that said, though couldn't you
> also just include the information in the HTTP header for HTTP? Do you think this is a sufficiently
> general issue that it merits a change to TLS.
> 
> -Ekr
> 
> 
> On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz <knekritz@fb.com <mailto:knekritz@fb.com>> wrote:
> 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 <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls