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

[Martin Rex <[e-mail]>]

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