On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell <fr...@baggins.org> wrote: > > > On 15/10/15 14:00, Martin Rex wrote: >> Is the particular interop problem that you want to address >> caused by a necessity to really process application data and >> handshake data with arbitrary interleave, >> >> or is it rather a problem of getting back into half-duplex operation, >> i.e. a client being able to continue receiving application data >> up to a ServerHello when it has sent out ClientHello, or a server being >> able to continue receiving application data up to a ClientHello >> (or warning level no-renegotiation alert) after the server has sent >> a ClientHelloRequest? > > The former. The existing code should cope with the half-duplex issue. In > the reported problem we (OpenSSL) are running as a server and we have > received application data from the Client *after* we have sent our > ServerHelloDone.
After thinking about this a bit this should be okay so long as you properly present the authentication state associated with the data. The hypothetical problem is using this to evade the protection of the secure renegotiation extension. As a solution the new authentication state should only be made visible to application code after receiving a CSS/Finished. This is supposed to have exactly the same semantics as pretending that the application data was sent before any handshake data. Unfortunately I don't know how to verify this. Can miTLS cover this case? > > Matt -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
