Re: [TLS] Summarizing identity change discussion so far

[Marsh Ray <[e-mail]>]

[e-mail] wrote:
> The security considerations section of this draft has to describe the
> fact that even with this fix, renegotiation does things that will
> surprise application developers,

Does it? This fix ensures that the same party is on each end for the
entire connection.

This rules out a MitM switching connections around. So the only
remaining issues must involve a client or server being able to switch
between certificates that he actually does have the private key for.
Clients are already expected to validate the server cert for any protection.

My impression is that the most surprising thing about renegotiation for
most app developers is that it can happen at all, and that their TLS
library may be silently handling it by default. If we make any
recommendations for TLS libraries it should be to not do renegotiation
unless the application asks for it by registering a callback.

> and can cause security
> vulnerabilities for some of them.

Do we know of any examples? I can only think of some very subtle and
hypothetical ones that require client and server apps that are already
coded for switching identities intentionally.

> That part we cannot avoid -- some text has to be included.
> 
> It's not absolutely required that the text makes recommendations how
> to avoid those vulnerabilities, but IMHO it would be a bit strange to
> just describe the security problem without saying anything how to
> avoid it...

Any security problems which remain after MitM renegotiation is fixed
will be interesting to research, but I just don't think we understand
them well enough yet to describe them in an official document.

- Marsh