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

[Dave Garrett <[e-mail]>]

On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote:
> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> > On 22 December 2015 at 13:25, Christian Huitema <[e-mail]>
> > wrote:
> > >> Unless I'm confused (which is possible given the time of night),
> > >> the intention, as you say, is to separate out the 0-RTT handshake
> > >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations.
> > >
> > > OK. That does not simplify implementations using running hashes...
> > 
> > It does if you consider the possibility of having to drop the 0-RTT data.
> 
> That's right. In fact, it may be a good idea to add to the spec a description of a "Failed 0-RTT handshake." If I understand correctly, the following will happen:
> 
> * Server will receive the client hello, ignore the Early Data Indication extension, and proceed as in 1-RTT.
> * Server will indicate that by not adding an Early Data Indication to the server hello.
> * Server will receive a series of 0-RTT messages that it cannot decipher, and just drop the messages.
> * Client will receive server hello, and proceed as per 1-RTT. Client API will signal that 0-RTT data was lost, application may decide to retransmit.
> * Server may send client authentication requests. Client will have to repeat the authentication messages, even if it already sent them as 0-RTT.
> 
> In that scenario, the handshake hash cannot include the 0-RTT messages, since the server does not in fact receive them, and they do not contribute to the state of the connection. 
> 
> We can of course debate whether the 0-RTT messages should also not be included in the hash if the 0-RTT exchange was successful, the messages were received, and they contributed to the state of the connection. If they are not included, then the "Finished" HMAC does not offer a protection against tampering. This may open the possibility of some kind of substitution or replay attack.
> 
> The failed 0-RTT handshake scenario also has interesting consequences on the Record layer. We have a legitimate scenario in which received records cannot be decrypted. This should not trigger alarms. And the numbering scheme should be robust against these missing records.

Do we have anything that protects against an intermediary stripping 0RTT messages from a handshake to force a fallback?

Could we just make the handshake hash use the encrypted messages, regardless of if it can decrypt them? (maybe for all messages?)


Dave