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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.