On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > Do we have anything that protects against an intermediary stripping 0RTT > > messages from a handshake to force a fallback? > > Yes: > 1. The EarlyDataIndication tells the server that some 0-RTT messages are > coming. > 2. The Finished in the 0-RTT flight covers the entire handshake flight, > thus preventing > tampering with those messages. > 3. The server's Finished covers the ClientHello, thus preventing tampering > with that.
#1 & #3 are easily dealt with by injecting bogus 0-RTT messages that get rejected, at which point a 0RTT could be prevented and we won't get to #2. So, the client sends a handshake with 0RTT, an intermediary strips it and replaces it with something that fills the slot, but will get rejected, the server rejects it and falls back to 1RTT, and then the client would have to accept this. This intermediary thus has the power to force any 0RTT attempt to fall back to 1RTT. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
