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 <e...@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 <knekr...@fb.com > <mailto:knekr...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
