On 15/10/15 00:04, Watson Ladd wrote: > On Wed, Oct 14, 2015 at 6:43 PM, Matt Caswell <fr...@baggins.org> wrote: >> >> >> On 14/10/15 21:42, Martin Thomson wrote: >>> On 14 October 2015 at 13:29, David Benjamin <david...@chromium.org> wrote: >>>> If you really absolutely must support interleave and can't avoid it, I >>>> think >>>> it being allowed everywhere except between CCS and Finished is probably the >>>> closest you can get to coherent semantics. "Coherent" here is, of course, >>>> all relative since renego is involved. >>> >>> I think that it needs to be more than that. I would say: >>> >>> 1. You should not interleave data with handshake messages from the same >>> flight. >>> 2. You should not report any change to handshake status until the >>> renegotiation is complete. That means no callbacks/events about new >>> peer certificates, or anything of that nature until you have received >>> and validated the Finished. You would have to exercise caution here >>> for the callbacks that are necessary during the process, like the >>> "please choose a certificate and private key to use" callback on >>> either side. >>> >>> If you can somehow manage to do all of that, then you might be able >>> get away with not halting progress entirely. Because - as far as the >>> application is concerned - application data is sent as though it were >>> before the renegotiation. In essence, you are keeping the application >>> ignorant of any changes until the whole process is over. >>> >>> I've heard it recommended that you add other stipulations, such as >> >> That would be very challenging to implement. Almost certainly not >> possible for the stable released versions. I would hesitate to do so for >> the new development version too without explicit published advice in the >> form of an RFC/errata...it would add significant complexity. >> >> It seems my options in reality are: >> >> 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. Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
