I assume that you would run a tight tolerance on the 0RTT resumption by saving the client's clock error in the ticket. That a way only clients with bad drift get no 0RTT. To do that all sessions need time.
I do not see how the server can do this in general without client help. But the solution also addresses Brian's concern. The client doesn't need absolute time, just relative time: How long since the ticket was issued. Then it's an addition to the psk_identity only. On 13 Mar 2016 1:49 PM, "Erik Nygren" <[email protected]> wrote: > That does seem like a good idea to include a client time stamp in the 0RTT > flow to let the server force 1RTT in the case where this is too far off as > this bounds the duration of the replay window. (I suspect we'll find a > whole range of other similar attacks using 0RTT.) An encrypted client > timestamp could presumably be probed by the server. (ie, if the server > response is a different size for timestamp-expired vs timestamp-not-expired > an attacker could keep probing until they change?) That does seem like > more effort, however. > > Erik > > > On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
