On Fri, Mar 24, 2017 at 1:47 PM, Roelof Du Toit <roelof_dut...@symantec.com> wrote:
> I was wondering if Section 4.4.4 requires an additional exception to allow > sending Application Data from the server prior to receiving the client's > Finished message? > > > > The current draft has the following in Section 4.4.4: > > *Once a side has sent its Finished message and received and validated the > Finished message from its peer, it may begin to send and receive > application data over the connection. Early data may be sent prior to the > receipt of the peer’s Finished message, per Section 4.2.7.* > Thanks, yeah, this text is old. Will see about fixing. > .. while Section 2 has the following: > > *At this point, the handshake is complete, and the client and server may > exchange application-layer data. Application data MUST NOT be sent prior to > sending the Finished message. Note that while the server may send > application data prior to receiving the client’s Authentication messages, > any data sent at that point is, of course, being sent to an unauthenticated > peer.* > > > > > > Unrelated, I was curious why the 'client_traffic_secret_0' calculation > does not include the 'Client Finished' message while the > 'server_traffic_secret_0' calculation includes the 'Server Finished' > message? After some digging I noticed that the split was added in Draft > 16, while Drafts 13 through 15 had it as just 'traffic_secret_0' > (calculated without 'Client Finished'). I'm guessing it does not really > affect the strength of the secret, but I was wondering about the asymmetry. > The principle is that all the traffic keys are computed at the same time. -Ekr > > > --Roelof > > > > _______________________________________________ > 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
