On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> 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)." Well, this is a general requirement any time the record MAC is bad: See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 "If the decryption fails, a fatal “bad_record_mac” alert MUST be generated." > 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. > If you have suggested text, I'd be happy to see a PR. > 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. ;) Merged. -Ekr > > Dave >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
