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). "Rock" meet "hard place". :-( Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
