On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson <martin.thom...@gmail.com> 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. > Indeed. This is, IMO, one of the core reasons renegotiation was a horrible mistake and one we should make sure never to repeat in the future. :-) I didn't mention it since it's more an API concern than what's over the wire, but that certainly doesn't make it any less a problem! What renego even means for the application data is extremely weird. A lot of TLS APIs and implementations I've seen don't do a very good job of scoping their private state or even public APIs properly, so it's very unclear what, say, querying the peer certificate even means at various points mid-renego. (Mid-initial-handshake is weird too, but most consumers are sensible enough not to query such stuff while some abstract "connect" operation is still going on.) This is especially problematic because handling renegotiations transparently seems a fairly popular implementation strategy. (Both NSS and OpenSSL do this. OpenSSL even allows them by default and doesn't have a good way to turn them off. Not sure about NSS. BoringSSL makes it opt-in.) Above all, by far the best way to handle renegotiation is "never do it, period". I think it's most important that any attempt to hammer down semantics in the "we already got it wrong" cases should be clear on this. New protocols should implicitly forbid renego, implementations should turn it off by default, and that at least gives a bounded body of existing mistakes to consider. David > I've heard it recommended that you add other stipulations, such as > > 3. The server cannot change certificate. > > I'm ambivalent on that because I don't believe it to materially change > the security properties (assuming that we have a good handshake, i.e., > at least R-I and session hash). I don't have proof of that, of > course. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
