On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote: > TLS isn’t a magical “transport security solution”, it provides a very specific > set of explicit security guarantees to the applications that use it. It can > be > used as a building block for the secure systems, but at the end of the day, > the > security of a system hinges on the designers’ understanding of the security > contracts provided by individual components. > > TLS 1.3 as-is does not remove any of the replay protection guarantees provided > by TLS 1.2. However, if the user chooses to waive said protection in order to > do 0-RTT, they can do that with an API explicitly designed for that purpose.
+1; In fact, I'd suggest sticking this almost as-is into the spec somewhere. > C. “Nebulous” replay bound. 0-RTT data can be replayed, but only for some > finitely bounded number of times. I initially wanted to call this “weak > replay protection”, but that felt too generous. > > Normally I would dismiss this as a useful security property due to its > inherent > vagueness, for the same reasons that “your server is too far away for > nanosecond-level timing attacks on Intel CPUs” is a property that no serious > cryptographer would admit in a research paper. However, you’ve pointed out > some > interesting side channel leaks, which exist even without 0-RTT, but can be > amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is a > meaningful property to provide. > > Let’s talk about what mechanisms are and are not viable for the nebulous > bound promise. There is one relatively straightforward mechanism for limiting 3rd party replay: A 3rd party replaying 0-RTT PSK will fail to successfully complete the handshake (after 1-RTT), as it would generally have the identity/ticket but not the key behind it (e.g. resumption_master_secret). The 0-RTT data will have already been processed, however a server detecting any PSK failure could then flag the offending ticket/IP and reject all future 0-RTT attempts for some time period (e.g. ticket lifetime). This would limit replays to one per server, or less if this banned 0-RTT state is shared across servers. The notable problem with this mechanism is that a 0-RTT DDoS, could easily balloon the state size rather significantly, if not careful. Servers would have to be fine with budgeting resources for a nontrivial state in the event of attack, even if they don't need it during normal operation, but that could at least be doable. A replay from the 1st party that is expected to have the correct key/secret or from a 3rd party that has stolen it would not be mitigated by this system, but that's much harder for an attacker to attempt, at least. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
