On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote:
> > What I am less confident about is the secure usage of features like 0-RTT, > 0.5 RTT, and post-handshake authentication. > Many researchers have looked at these aspects (and they can correct me if > I am wrong) but the security guarantees we can prove for these modes is > much more limited than for the regular 1-RTT handshake. My concern is that > these features will inspire new usage patterns will emerge for TLS 1.3 that > have not been adequately studied. I am not sure what we can do about that > except maybe work harder on the security considerations. > I'll be at TLS:DIV and presenting on 0RTT, which is forcing me to finally nail down all of my concerns in a more concrete and data-driven form. I do think it's fair to say that 0RTT is known to be insecure, in the sense that there are real-world attacks it will enable, and I haven't seen any of those disputed. Wether we should accept those is a matter of trade-offs, I don't think we should; they seem quite serious and really point the gun at the feet of the user. A warning saying 'You shouldn't use these without an application profile' is already failing in the market; with vendors deploying 0RTT anyway in unsafe cases. It goes against all of the neat encapsulation we've been trying to build for secure primitives. So for now, here's my high level summary: Replayability issues: 0RTT data is replayable, we know this. It includes a weak clock-based protection against against replay. If we take the CDN use-case, and realistic values for latency and clock drift, the mitigation ends up permitting many billions of replays. This is much much more than similar issues that have brought up before (e.g. browser retries). 1. Applications must be coded defensively against replay - e.g. they must be idempotency. But this is hard - and for mutating actions can only truly be achieved with tight-bound transactions at the application layer. Enclosing transactions don't work. But 0RTT is being incorporated "below" the application layer in a way that is very very likely to lead to a mis-match of expectations. 2. We can say that 0RTT shouldn't be used for non-mutating actions. But this is bad for two reasons. Reason "A" is that many services have throttles, even for reads, to prevent overload and abuse. If an attacker than replay 0RTT data and exhaust a throttle, this completes a denial of service attack, Reason "B" is that 0RTT is a very effective way to improve the performance of uploads. For architectural reasons, it's common for users to send photos over messaging, and for these photos to be uploaded to storage engines over TLS, while the URL is shared over the messaging protocol. This should be a good and valid use of 0RTT, but it certainly mutating and requires idempotency. Suggested mitigation for issues 1 and 2.: The 0RTT section should be unacknowledged at the TLS protocol layer. The client should send it, but the TLS layer should have no knowledge of whether or not it was decrypted/accepted. Instead the application should either tolerate it being re-sent as part of the regular application data, or should acknowledge it explicitly at the application layer. Side-channel defensiveness issues: 3. Replaying 0RTT data makes statistical analysis of side-channels far easier, at the application level and at the crypto level. At the crypto level, 0RTT opens us up to implementation side-channels that merely decloak the plaintext (rather than key) in a way we haven't quite had before. The attacker can feed the cipher text billions of times and learn things about it. The previous mitigation would help with this. At the application level, 0RTT makes it much easier to use application-level side channels. Here's a simple example: User requests some content from a CDN - what was it? Suppose we have a billion candidate URLs we want to probe and see what it was. We can make trial downloads of our candidates from the CDN and see what's warm in the cache; that helps us narrow it down. But with 0RTT we can also replay the request against other/cold CDN nodes, and cause them to fetch the target resource, which makes this kind of attack exponentially easier - to the point that it is trivial. There are neat combinatorial techniques that make finding the needle in the haystack easy. That's a pretty big dent in secrecy. 4. 0RTT data loses Forward Secrecy. This is a big deal because FS is one of our goals for TLS1.3. And it's a really big deal because 0RTT is where the most valuable parts of a session are likely be. It's the URLs you're accessing, it's your authentication tokens, and your credit card number. These all go in the early-phase of real-world requests precisely because the server needs them to process. If we don't provide FS for these, but do for the HTML you are downloading, is that really a wise combination of trade-offs? It seems very strange. Suggested mitigation for 3 and 4: 0RTT data shouldn't use session tickets. It should use server-side state, like a traditional session cache, and the keys should be single-use. E.g. use it once from the cache, and then erase it. This restores forward secrecy, prevents replays, and also is more robust against other side-channels (tickets are themselves more open to side-channel abuse, because tickets are replay-able). The counter-argument I've heard here is that "CDNs don't want server side state". But TCP fast open already relies on server side-state, CDNs are themselves massively distributed caches anyway, and route flaps between nodes seem to be uncommon. I don't quite see the big deal and there doesn't seem to be another way to provide security. Tickets with replay-ability just don't achieve it. I would also argue that TLS1.3 should not support tickets at all; and only cached single-use sessions. I recognize that will take a compelling set of arguments, and is a long way from the consensus. That's is why I'll be presenting in more detail, including about the economics of all of this. I'll ask for open minds. > -Karthik > > On 5 Apr 2017, at 10:44, Sam Scott <sam.scot...@gmail.com> wrote: > > I don't know what the state of the various modelling efforts is, though I > imagine > this will be a topic at TLS:DIV at the end of the month. We did discuss > the various > cryptographic changes in -20 (specifically the extra key derive stages and > the > handshake hash reification) with a number of cryptographers before > incorporating. > Perhaps some of the analytic groups on-list would care to comment? > > > From our* point of view we're pretty happy with the current state of the > spec. > Our initial results confirm that TLS achieves the core security properties > (secrecy and authentication). More specifically, we prove an absence of > attacks > against those properties in our model. > > We're currently waiting for the last version of the spec to be finalised > so that > we can make a more definitive statement and share our final results. > Although we > do not expect our analysis to be affected by the recent changes to the > spec, we > will still need to update our model and re-prove everything, which is > quite time > consuming. We will be talking at TLS:DIV so can share more then, including > what > is and isn't captured by our model. > > * Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan Hoyland, > Sam Scott, and Thyla van der Merwe. > > _______________________________________________ > 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 > > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
