Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

[Eric Rescorla <[e-mail]>]

On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <[e-mail]>
wrote:

> On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <[e-mail]>
> > wrote:
> > > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> > > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <
> [e-mail]>
> > > > 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
>