Re: [TLS] matching identity, by default

[Nelson B Bolyard <[e-mail]>]

On 2009-12-03 10:54 PST, Marsh Ray wrote:
> Bodo Moeller wrote:

>>> These may be communicated over the same pool of active socket
>>> connections, as Nelson Bolyard of NSS (heir of the Netscape legacy
>>> implementation, twice removed) has described.

NSS _is_ the Netscape legacy implementation, much evolved.

>> Where has he described this?  (Sorry -- I've tried to find something
>> using various keywords, but to no avail.)
> 
> Sorry, I think it may have been a private mail. Nelson, would you mind
> posting that? I refer to it often. I have it in my box dated 10/16/2009
> 6:27 PM Message-ID: <[e-mail]>.
> 
> I'm sure he wouldn't mind me sharing this tidbit:

I don't mind a bit.

> "It is also possible that, in response to a client hello request, the
> client will send a client hello bearing a session ID that is not empty
> and is NOT the session ID of the session presently in use on that
> connection.  This can happen when the client has multiple connections
> going in parallel between the same client identity session cache and the
> same remote server."

To explain that slightly, NSS explicitly allows a process to act as multiple
independent client entities, e.g. multiple virtual http clients,
each with its own separate TLS session cache, so that each entity can
restart its own TLS sessions, and not accidentally restart sessions of
another entity.  This greatly facilitates writing test clients that simulate
large numbers of independent clients all pounding on a test server for
(e.g.) benchmark purposes.

Most client apps only operate as a single entity and only use one client
identity cache, so it was a detail that's not necessarily important to this
discussion.  But if an app wants to have multiple connections to the same
server, with some of them client authenticated with some identity, and
others not authenticated, or authenticated with a different identity, then
it should use a separate cache for each of those identities, including one
for the anonymous (non-authenticated) identity.

A single client entity may have multiple sockets open, with multiple TLS
connections to the same server, and multiple of those connections may be
using the same TLS session (the same session ID).  Generally, whenever any
handshake (initial or renegotiation) occurs with a server, the code finds
the TLS session most recently established with that server in that client
entity's session cache, and offers that session's ID in the client hello.

So, if a client has multiple connections going to a server, all sharing the
same client entity's session cache, and it renegotiates on one connection
with a full handshake, establishing a new TLS session (with or without
client authentication), then the next time it renegotiates on any connection
to that same server, it will offer in the client hello the most recently
initiated session ID, even if that is not the session ID that was already in
use on that connection.

> Now I don't perfectly understand how Mozilla handles its "client
> identity session cache" (I suspect no one does), 

<sound src="blowing_raspberry.mp3"/>

> but it sounds plausible to me that renegotiation with resumption could,
> in theory, switch between differing client certs over the same
> connection.

Switch between different TLS sessions that had bee previously authenticated
with different certs.  Yes, I agree completely.

I see TLS as being capable of multiplexing multiple independent sessions
over a single connection.  Perhaps it's not terribly efficient at that --
the round trip time cost of switching sessions (doing session-restart
handshakes) is at least as great as the cost of a 3-phase connection --
but I read nothing in the SSL/TLS specs that disallow it, and I have seen it
used, at least experimentally in development.

> This might be fun to test, actually.
> 
>>> If someone wants to write a TLS application layer protocol that way,
>>> there's no good reason for the spec to prohibit it at this stage in
>>> the game.

I agree that we should not absolutely prohibit it.  But clearly most of the
people who have ever coded apps to use SSL/TLS have never contemplated this
session multiplexing capability, and have imagined that TLS was always about
a secure connection between a single pair of these (loosely defined)
entities.  So, it might be good to suggest that TLS implementations operate
BY DEFAULT in a mode that supports that all-too-common assumption, and if
desired, offer a session multiplexing mode as a selectable alternative that
is not the default.  But this is API advice.  I see no reason for the
over-the-wire protocol specification to prohibit it.

> What I think would be far more useful is a practical treatment of the
> best practices and possible pitfalls for implementing and using typical
> library APIs. Some of this is in Appendix D. Implementation Notes, but
> it could be given its own section with advice like:
> 
> * Although most TLS libraries will properly validate a cert, the
> application code is usually still responsible for checking that the cert
> identifies the intended host. This is because the exact method to be
> used depends upon the application protocol in use. This check MUST be
> done at the earliest opportunity during the handshake process. This
> usually necessitates an application-supplied callback function be
> registered with the TLS implementation. Returning a failure code from
> the callback MUST terminate the handshake.
> 
> * The TLS protocol allows application data to be interleaved within
> rengotiation handshake messages. Sometimes this is desired, but may
> require extra care. The application-supplied callback and TLS library
> normally SHOULD discard any buffered plaintext at the point of
> renegotiation. It is recommended that TLS libraries default to neither
> sending nor accepting of application data during a renegotiation
> (between the Hello and the Finished handshake messages).
> 
> and so on...

I agree that implementation guidance is a good thing.  For a long time,
there has been a certain tension between those who think that IETF RFCs
should be only concise and precise specifications, with a minimum of extra
verbiage, and those who think that implementation guidance is important,
especially in security protocols.  Count me in the latter group.

In the history of SSL/TLS we have seen numerous instances where a little
more explicit implementation guidance would have gone a long way to avoiding
certain divisive implementation problems.  One example is the stripping of
leading zero bits from derived DH/DHE pre-master secrets, which seemed
obviously wrong to mathematicians and obviously right to most of the early
implementers (but I digress).  One of the later versions of TLS addressed
this explicitly.  It could have been avoided with a little more guidance
from the beginning.