Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to

[Martin Rex <[e-mail]>]

Simon Josefsson wrote:
> 
> Nicolas Williams <[e-mail]> writes:
> 
> > On Tue, Mar 23, 2010 at 09:56:12PM +0100, Simon Josefsson wrote:
> >> I recall that both OpenSSL and NSS drive TLS renegotiation internally
> >> (i.e., TLS apps are not required to do the handshake).  For GnuTLS, it
> >> is the apps that drives TLS renegotiation.  Can someone confirm/deny my
> >> recollection?  As far as I recall, the reason the TLS renegotiation
> >> issue was problematic for OpenSSL/NSS (and not for GnuTLS) was that the
> >> former libraries drives renegotiation internally in the library.
> >
> > But what is the trigger?  Key aging?
> 
> A renegotiation request from the peer, as I understood it.


That was my understanding as well.

Whether the server tries to request a client certificate on the
initial handshake or whether it tries to request it after having
seen the request (and before sending a 401 Unauthorized reply)
is a configurable behaviour of some servers.


Client apps on OpenSSL style APIs usually do not know, and should
not have to care, whether the server is configured in that
originally very dangerous fashion and that the clients local
TLS implementation performs the TLS renegotiation transparently.


When it is the client app that retrieves the ChannelBindings information
from the TLS implementation and feeds it into gss_init_sec_context(),
then the channel binding information should be sticky to the
TLS connection handle (which represents the communication channel
as seen by the application).


I believe we agreed and documented in the Security Considerations
section of the TLS renegotiation RFC that a change in the servers
identity during a server-triggered TLS renegotiation, which is not
necessarily visible at the API used by the client app, may come as
a surprise to that client app and should _NOT_ be the default.


-Martin