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? -Martin Matt Caswell wrote: > >>> 1) Allow interleaved data everywhere except between CCS and Finished, as >>> per the (hopelessly unclear) RFC. This would leave us conformant, would >>> solve our interoperability problems, but is a "highly dangerous idea" >>> according to your advice. >>> >>> or >>> >>> 2) Leave things as they are now where we abort on interleaved >>> application data. This would leave us unconformant and with an >>> interoperability problem which is causing real issues for users (who >>> will point the finger at us for failing to fix it). >> >> It takes two sides here to have an interop problem. What >> implementations are doing this? > > The specific report I have is for Oracle JRE 1.7.0_71 and 1.7.0_75 but > my assumption is that this affects all Oracle JRE versions. > > The problem ticket in question describes a scenario where a PostgreSQL > server (which uses OpenSSL) is talking to a PostgreSQL JDBC client. Due > to that fact that these connections are long running, PostgreSQL server > has a config parameter "ssl_renegotiation_limit" which triggers a > renegotiation after a certain amount of data has been transferred over > the connection. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
