Our state machine design in miTLS was quite deliberate, and based on our interpretation of the TLS 1.2 spec. It is possible that we got this interpretation wrong, but maybe the protocol authors can clarify the intended behavior.
However, I think that looking at the Handshake protocol message sequence (Figure 1) for guidance is misleading, because this sequence only concerns the first handshake and does not handle renegotiation. Otherwise, all messages would be marked as optionally encrypted. A proper interpretation of this issue must take into account the two-layer Record/Handshake split that is inherent to TLS 1.2. For example, one interpretation is that the CCS message changes Record state and Application Data can then directly interact with Record without necessarily being aware of Handshake status. In any case, a note about the miTLS security theorem. In miTLS, every application data fragment is labeled by the epoch in which it is sent and received. miTLS itself does not concatenate data from different epochs, but gives applications enough information about the two epochs so that it can choose to combine data from different epochs (say if the certificates used in the two epochs are the same.) So, the miTLS security theorem shows that sending and accepting data during a renegotiation handshake is fine, as long as: (a) this data is treated as belonging to the previous epoch, not the next one, and (b) no data is sent or accepted between CCS and Finished in either direction. Notably, this means that if the new epoch uses new certificates for the client and/or server, any application data sent during the handshake does not get to be authorized with the new certificates, since it still belongs to the old epoch. If the current handshake completes and then new data is sent, the new data will be labeled with the new epoch. Now, the application on top of TLS gets to decide whether it wants to concatenate the data streams from the two epochs. For other implementations, I do agree that sending or accepting data once renegotiation has begun but before the new handshake has finished can be dangerous, because it is sometimes unclear whether this data will be associated with the as-yet-unconfirmed parameters of the new handshake. Best, -K. > On 06 Dec 2015, at 16:50, Hubert Kario <hka...@redhat.com> wrote: > > On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: >> Hubert Kario <hka...@redhat.com> writes: >>> miTLS does accept Application Data when it is send between Client >>> Hello and Client Key Exchange and rejects it when it is sent between >>> Change Cipher Spec and Finished. >> >> Given that miTLS is a formally verified implementation, would this >> imply that there's a problem with the verification? "Beware of bugs >> in the above code; I have only proved it correct, not tried it"? > > This behaviour is dictated by the TLS 1.2 RFC, although partially > indirectly: > - the acceptance of application data during subsequent handshakes is > explicit > - the no application data between CCS and Finished is implicit, as it > is only stated that the Finished MUST be the next message directly > following CCS. And since CCS and Finished have different content > types, that means that the limitation is cross-content type, unlike > for other handshake messages > > So on the face of it, behaviour of miTLS is correct. > > Now, as we've discussed on the OpenSSL bug tracker. This does cause > problems if we have certificate based client authentication and the TLS > library returns client authentication data from *new* handshake while it > still has not received and processed Finished message. If that is the > case, then the attacker may force the server to process messages under > authority it still didn't verify. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
