Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:

[Martin Rex <Martin.Rex at sap.com>]

Nicolas Williams wrote:
> 
> Another problem that Larry has is that in his implementation what I call
> a "TLS connection" is called a "security context", and if the
> application re-handshakes (e.g., to authenticate a user) then the result
> is a second security context -- we need to be extra clear that it's the
> client Finished message from the _first_ "security context" that we're
> after.

Microsoft's implementation (which could be the one referred to by
Larry's implementation) has a silly design flaw in its TLS renogiation,
and I'm not sure that the previous text is a way to fix it.

It is possible to configure Microsoft IIS in a fashion so that it
will first perform a TLS handshake with a server-only authentication,
and after having received the HTTP request, it will re-negotiate and
ask for a client certificate.

In the ClientHello, the client will send no TLS session ID (since
the purpose is renegotiation -- aka a full TLS handshake.
Microsoft IIS will send back a ServerHello with an entirely new
TLS session ID.  In my TLS clients, I will drop TLS sessions
from the client-side cache for which the server asks for
re-negotiation (actually replace them with the resulting
renegotiated TLS session).

Unfortunately, this doesn't save a TLS handshake on the next
connect, Microsoft IIS will force another renegotiation when
that re-negotiated session is resumed, resulting in yet
another new TLS session.

From my experience, it is possible to TLS resume both, the original
and the renegotiated session when Microsoft IIS is the server,
and it will force through re-negotiation on both.  So an IIS
configured like that will artificially inflate its server-side
session cache and impose unnecessary re-negotiations on
the TLS client and on itself.


And btw. Channel Binding at the application layer and
transparent TLS-session renegotiation at the TLS layer appear
somewhere between hard-to-do and mutually exclusive--in case
that the TLS session renegotiation happens totally transparent
to the application.


-Martin