On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote: > 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: > > 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).
This last bit stops this, yes. I would prefer the spec say this very explicitly, as right now it doesn't and all I see is a line saying: "If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus falling back to 1-RTT)." The current text doesn't explicitly say how to handle 0-RTT data that it thinks it should be able to decrypt but can't. After rereading things a bit I think you're correct in that the correct course of action the spec currently expects is to abort, however implementers frequently err on the side of working partially vs not at all when given any wiggle room. A clear hard "MUST abort" on failed decrypt of 0RTT data would deal with this and avoid any other possible misunderstanding. Either do or do not; no try. > 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. Also, I found a typo in the early data section. The config ID was referred to by two names. PR filed. ;) Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
