On Thu, Dec 24, 2015 at 3:40 PM, Christian Huitema <huit...@microsoft.com> wrote:
> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote: > > > > On 22 December 2015 at 13:25, Christian Huitema <huit...@microsoft.com> > > 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. > This seems exactly correct. 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. > Correct. 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. > They are included in the client's 0-RTT Finished, so as long as SS is not compromised, you should not be able to modify them. They are not protected against modifications if SS is compromised, whereas other messages are covered by the server's signature. 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. Yes. Resetting the sequence number as proposed by Fournet et al. and in WIP-11 makes this easier. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
