On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> 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. > This doesn't sound correct. 1. The client sends a ClientHello with an EarlyDataIndication indicating configuration=C (and server key g^s) and ClientHello.key_share = x. 2. The server processes the ClientHello and determines whether 0-RTT will be accepted or rejected based purely on the ClientHello. I.e., it doesn't need to read any more messages before deciding this [0]. If it decides to accept 0-RTT then it expects the next messages to be 0-RTT handshake messages encrypted with SS = g^xs. If those messages don't decrypt properly, then it needs to fail the entire connection (fatal alert with bad_record_mac). 3. The attacker *could* modify the ClientHello to replace C with C', which would cause the server to fall back to 1-RTT, but then the server's CertificateVerify and Finished would both be incorrect, causing the handshake to fail when the client tries to process them. If you still think I'm wrong here, it would help me if you provide a ladder diagram indicating the attack you are concerned about. Thanks, -Ekr [0] Technically speaking, it should be possible to send ServerHello before even reading the remainder of the first flight.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
