On Thu, May 04, 2017 at 10:12:34PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > > > > > That seems like an inconsistent position to take (don't do this, but if > > you ignore me, do this in this fashion). Advising application profiles to > > consider one of those things might be better. > > > > That's just incompetent writing by me, I guess. > > For 2, I meant "If there is an application profile allowing 0-RTT, but it > doesn't say you don't > need mitigations, then you MUST..."
I think the two methods (use-once session database and strike register) should additionally be formulated so that those have sufficient atomicity to eliminate 0-RTT replay. This of course impiles that the scope of 0-RTT is sufficiently small for synchronization to propagate quickly enough (this probably limits the scope to a datacenter, but this should not be a problem in practice). Then clients should also be restricted to using the same ticket just once for 0-RTT (absent a application profile), with due atomicity. Also, I think use of 0-RTT exporters should require atomic session database or strike register, no matter what application profile says, as otherwise 0-RTT exporters become insecure. Obviously, these 0-RTT safeguards don't need to apply to 1-RTT using a dynamic PSK. That can be reused (obiviously at cost of linkability). Also, a trick: The first binder makes a good identifier for the ClientHello for purposes of 0-RTT replay detection. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
