On Sun, Dec 6, 2015 at 1:59 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > >> On 6 Dec 2015, at 4:44 AM, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> If you disagree, please cite the sentence of the TLS >> RFC which prohibits accepting application data records during the >> handshake. > > OK, I’ll bite. Top of page 36: > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > Figure 1. Message flow for a full handshake > > > See? Application data goes *after* the Finished message. Not between > ClientHello and anything else. Now this swim track diagram may not look like > a formal definition, but RFCs are written to be processed by humans, not > computers. If I add some application data in the middle there like this:
(Ever meet a tax lawyer?) But is it defining the flow of messages in the Handshake protocol, or on the wire? The reason I think it's the first is that the RFC several times explains that different layers above the record layer are independent. Even if that's prohibited, there is no requirement to send an alert if that happens: allowing it is not prohibited. In fact several emails in this thread show that other implementers agree with my reading, and that there exist implementations that have this behavior. I hope that whatever renegotiation replacement we have in TLS 1.3 explicitly specifies that this sort of trick is allowed. > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Application Data > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > > Any human can see that this is not the same as what’s in Figure 1, and thus > is wrong. We don’t need the RFC to provide a regular expression or a state > machine diagram to figure that out. > > Yoav > > > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
