i mentioned it here, but perhaps it's not clear enough. "If data can be replayed a large number of times, additional attacks become possible. Specifically, attackers can use multiple replays to exploit information leakage via side channels such as timing network caches or measuring the speed of cryptographic operations."
I've got some other comments to resolve Monday I'll try to get to this then, but I'd also welcome suggested text on the PR. -Ekr On Fri, Jun 23, 2017 at 10:27 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Fri, Jun 23, 2017 at 10:44:00AM -0700, Eric Rescorla wrote: > > > > On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <j...@salowey.net> wrote: > > > > > Discussion on this topic is dying down, can you post a PR so we can see > > > the proposed text. There is still some discussion on the API thread so > > > there may be some additional modifications coming in that area. > > > > > PR up: > > https://github.com/tlswg/tls13-spec/pull/1034 > > I didn't see any mention of the cache probing attack. > > I.e., Leak data from 0-RTT requests (especially URLs) by first priming > caches using 0-RTT replay and then probe the caches using normal > requests. > > This attack can be viable even at low replay count, it isn't like the > others that require very high number of replays. And in fact, it > benefits from having numerious zones. > > > E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of > each other seem vulernable to abusing this for discovering HTTP GET > URLs in 0-RTT requests. > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
