On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose <kr...@krose.org> wrote: > On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara <ilariliusva...@welho.com > > wrote: > >> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the >> > table of handshake contexts under "Authentication Messages", >> specifically >> > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm >> > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is >> > accepted, is the second Finished message from the client ("{Finished}") >> the >> > same message encrypted differently (using the handshake traffic secret)? >> >> No, there is no difference in ClientFinished in case of 0-RTT accept or >> reject (other than the contents of the CH and EE hashed in). >> > > Still confused. :-) > > In the message flow for 0-RTT, there are two Finished messages sent from > client to server. One is sent right after CH, and is protected by the > client_early_traffic_secret: (Finished). The other is sent after the server > sends its Finished, and this is protected by the handshake_traffic_secret: > {Finished}. > > In the table under "Authentication Messages", there are four rows, one for > each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshake. > > Which handshake context is used for the (Finished) message and which is > used for the {Finished} message? > > The thing that protects the 0-RTT data from substitution is the record >> protection MACs that are made using key derived from the PSK secret. So >> if the PSK secret is unknown, the key for 0-RTT can't be derived, and >> as consequence, 0-RTT data can't be altered (there's end-of-data marker >> too, preventing truncation). >> > > Altered is one thing, and I agree that is prevented; I'm talking about > substitution. > > >> And basically, ServerFinished MAC covers everything up to that point, >> and ClientFinished MAC covers the entiere handshake (0-RTT data not >> included). >> > > So client Finished doesn't protect 0-RTT data, but... > > >> You can't swap out 0-RTT data (without PSK keys). One can only create >> new connection attempts (that fail!) with the same 0-RTT data (and the >> same ClientHello) before or after the real connection (if any, it >> could be supressed, in which case you would get only failed handshakes >> with 0-RTT data). >> > > This is exactly what I'm trying to understand. What specifically prevents > this swapping? I.e., what ties the 0-RTT data sent on a particular > connection to the rest of that connection, such that replacing that 0-RTT > data with 0-RTT data from a previous successful connection will cause a > failure? >
The 0-RTT traffic key incorporates the ClientHello.Random which is tied into the full handshake. -Ekr > > Kyle > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls